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Abstract 

Effective is a CH — h library which provides the user a toolbox to 
study the effective action of an arbitrary field theory. From the field con- 
tent, gauge groups and representations an appropriate action is generated 
symbolically. The effective potential, mass spectrum, field couplings and 
vacuum expectation values are then obtained automatically; tree level 
results are obtained analytically while many tools, both numeric and ana- 
lytic, provide a variety of approaches to deal with the one-loop corrections. 
This article provides a guide for users to who wish to analyze their own 
models using Effective. This is done by presenting the code required 
and describing the physics assumptions behind the code. The library can 
be extended in many ways and discussion of several such extensions is also 
provided. 
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1 Introduction 

The effective action of a model characterizes many of its important features. 
Using the effective action one is able to study the loop corrections and renor- 
malization group of a model, the nature of spontaneous symmetry breaking and 
the mass spectrum P^. This makes the effective action a powerful object to 
investigating phcnomcnological aspects of a model. 

It is generally agreed that there will be new physics beyond the Standard 
Model (BSM). The exact nature of this physics is still unknown and many ideas 
exist about its nature (see for example or PJ). In order to validate these 
new ideas, one must show that the tree level and one-loop results of this model 
agree with our current knowledge of the Standard Model. Additionally, new 
particles, their mass spectrum, couplings and symmetry breaking mechanisms 
must be elucidated. Often one wishes to only slightly deviate from an existing 
model by introducing a new field or a new interaction. Such deviations can often 
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create large differences in the structure of the model, particularly at one-loop. 
Existing codes for determining the spectra of models such as SOFTSUSY 0], 
ISASUGRA [S] and SUSPECT [S| do so for a particular model and are not easily 
extensible to study models with a changed field structure. We believe that this 
flexibility will be important in the post-standard-model era, as it will be more 
important to quickly get an approximate analysis of a new model, rather than 
to develop a very accurate code for a well understood model. 

Presented here is a new C++ library which provides a toolbox for the study 
of an arbitrary model. The code has been designed with the flexibility to allow 
a user to change the tools in the toolbox to suit their own purposes. 

1.1 What is Effective? 

In order to facilitate exploration of new physics an analytic tool has been cre- 
ated that automates many of the various uses of the effective action. The tool 
operates analytically when possible but reverts to numerics when necessary. 
Our code typically treats the tree-level action analytically while evaluating loop 
corrections numerically. This way the analytic structure of the tree level action 
can be derived and the consequences of the addition of new terms studied. The 
effect of symmetry breaking mechanisms on the physical masses and couplings 
of the action can be studied numerically in the same framework. 

Our solution is presented as a C++ library Effective. This library pro- 
vides a toolbox for the user to study an action and variants of that action. Ef- 
fective can be used to study many models with interesting phcnomcnological 
features. Examples include reggeized gluons [7] and R-parity violating SUSY |SJ 

It is possible to build extensions to the library to study virtually any model 
which can be written on paper. This code does not provide a simple executable 
to study an arbitrary model. Instead, a user must build their model with the Ef- 
fective library and create an executable that probes the desired physics of the 
model. The code can be freely obtained from the Effective web-page which 
is currently at the URL: http://stephens.home.cern.ch/stephens/effective. In- 
stallation instructions and full code documentation may also be found there. 

1.2 Library Features 

Effective has been written in object-oriented C++. This code has been de- 
signed for extensibility from the outset. The possible extensions will be discussed 
in section^J The code is built on the GiNaC algebraic engine JOj; as GiNaC 
is provided as a C++ library our code is seamlessly integrated with the analytic 
engine. Not only does this reduce computational overhead but allows for the im- 
plementation of many complicated routines, many of which would be extremely 
cumbersome in the languages built into proprietary analytic software. 

This code was initially developed to provide some of the same features found 
in SUSY spectrum generators such as SOFTSUSY gj, ISASUGRA and 
SUSPECT |5j. As such this tool can automatically generate the one-loop mass 
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spectrum of a model. The parameters can be run between different scales accord- 
ing to the renormalization group equations (RGE) in order to give a consistent 
parameter set. In this version, the RGEs need to be provided; a future extension 
to generate the one-loop RGEs automatically is planned. 

It is worth noting that this code is not intended to replace the much more 
efficient and accurate codes like SOFTSUSY, ISASUGRA and SUSPECT. 
Where dedicated code for a model exists, it will be faster and more reliable. 
Instead, this code can mimic the physics present in those codes, as well as many 
other actions and symmetry breaking mechanisms. Effective should be used 
to pioneer the study of a new model, with dedicated code for the model being 
written when it is clear it is interesting enough for a more precise analysis to be 
worthwhile. 

1.3 Organization 

This article is structured in the following way. In the first section the field 
content of a model is discussed. The default properties and interactions of the 
fields implemented in Effective are given and the routines needed to include 
the desired fields in a users model are presented. Also, the discussion about the 
vacuum expectation value (VEV) of a field is given in this section. 

The user can also implement additional interaction terms, such as Yukawa 
couplings. The routines used to specify these are discussed in section [21 For 
SUSY models, specification of the superpotential will imply further couplings 
between the fields. Once these three features are implemented the effective 
action can be derived. 

Next, we discuss how Effective can be used to analyze the model specified. 
The first step in this process is the generation of the effective potential from the 
action. This is minimized to obtain the vacuum expectation values (VEV). This 
process is given in sectional Next comes determination of the mass matrices and 
field couplings. The appropriate calls to the library are discussed in section [H] 
along with the routines used to access the mass matrices and mixing angles. 
The one-loop corrections to these matrices and mixing angles are also discussed 
in this section. The last feature of building a model is the RGEs. These are 
discussed in section Wc then present the way in which the specification of 
additional obscrvables which one wishes to calculate using Effective can be 
carried out by defining appropriate Feynman diagrams. 

All of the required routines in sections 121 71 will be discussed in terms of 
the electro-weak model. The full definition of this model will be given in the 
appendix and two examples using this model to produce some physical results 
will be given in section ITOI 

Section 1111 is reserved to discuss some of the various ways in which a user 
can define their own classes to replace the default ones in Effective. These 
customizations allow the user the possibility of implementing almost any feature 
they would like. Unfortunately, to customize the code, one must have strong 
C++ knowledge as well as a good understanding of the GiNaC engine. This 
section will be quite technical and as with most programming, to truly appreci- 
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ate the content one must try to implement things for themselves. To that end 
more programming oriented tutorials can be found on the website. 

2 Field Content 

Definition of the field content of a model consists of several parts. First one must 
define the gauge groups that define the interactions of the fields. The group 
structure is defined by the class GaugeGroup. Once the group has been specified 
we define the model's field content. There are two types of fields. The gauge 
bosons or gauge supermultiplet is a mediator of the interactions described by 
the gauge group; these are provided by the class GaugeField. The matter fields 
interact with the GaugeFields and with each other based on representations 
of the gauge group. These are described by the class MatterField. Once the 
GaugeFields and MatterFields are defined, one specifies for which scalar fields 
the effective potential will be analyzed to determine whether they will have 
non-zero VEVs. 

It must be noted that the class Field and its subclasses represent a set of 
fields which share the same properties. For example the colour octet of gluon 
fields are all contained in one GaugeField object. 

2.1 Gauge Groups 

Effective has three subclasses of GaugeGroup defined. These are UIGroup, 
SU2Group and SU3Group. Other groups could be implemented. This is discussed 
in section ITT1 

The GaugeGroups of a model are defined in the user supplied routine void 
createGaugeGroups () . In the electro-weak model we have the group structure 
SU{2) x U(l), to specify this we write 

void ElectroWeak :: createGaugeGroups () { 

addGaugeGroup (new UIGroup ("Ul" , "{g'}", this, Ulb)); 
addGaugeGroup (new SU2Group("SU2" , "{g_W}", this, SU2w) ) ; 

} 

This code block shows how to create the GaugeGroups and include them into 
the model. The function addGaugeGroup () adds a pointer to a GaugeGroup into 
the model. The constructor for the groups takes 4 arguments. First is a name 
which the group will be referenced by; this name also doubles as the plain text 
label for the coupling of the group. The second argument is the LaTeX name of 
the group's coupling parameter. The third argument is a pointer to the model 
which this group belongs to and the last argument is an integer number unique 
to the group. This is referred to as the line of the group. This allows multiple 
groups with the same group structure, while still keeping the properties of the 
groups independent of each other. 



5 



2.2 Gauge Fields 

Now that the gauge groups are defined, the gauge fields can be given. These are 
fields which mediate the interaction defined by the group. The kinetic terms of 
the effective action for the fields arc defined by the spin of the field and whether 
it has a supersymmetric partner. In Effective there are three default spin 
classes implemented. These are VectorSpin, FermionSpin and ScalarSpin. In 
Effective a GaugeField with VectorSpin has the following kinetic term 

~GF(V) _}_panVT?a m 

^kin — A r r nw K 1 ) 



where the sum over a is implied and 

? a — B A a 



F" = dpAl-dvAl+gf^AUl. (2) 



In these equations the indices are in the adjoint representation and f abc is the 
structure constant of the group, A't is the vector field and g is the coupling 
constant of the group. As we wish to support N = 1 SUSY, we also provide for 
spinor fields in the adjoint representation. If the GaugeField is a fermion field, 
the kinetic term is 



with 



4ln (F) = -ia^ a Df\ b , (3) 



Df = S^dp + igf^Al. (4) 



Again, g is the coupling constant of the group, f abc is the structure constant of 
the group and A° is the vector field which mediates the interaction. A a is the 
gauge fermion and are the spin matrices 
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In Effective, fermions are treated as Weyl fermions and the object is 
merely a placeholder representing the spin structure. If one wanted to code the 
action in terms of Dirac fermions, this could also be done. 

Effective by default has only implemented the terms which correspond to 
the N=l SUSY case. As such, there is no implementation of a gauge field with 
scalar spin. This is an extension that could be easily added, however. 

Now to see how the B and W bosons are added to the electro-weak model 
we provide the implementation of the void createGaugeFieldsO routine. 

void ElectroWeak: : createGaugeFieldsO { 
VectorSpin v; 

addFieldC'B" ,new GaugeField ( "B" , "B", v, getGaugeGroupC'Ul"))) ; 
addFieldC'W" ,new GaugeField( "W" , "W" , v, getGaugeGroup("SU2"))) ; 

> 
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From this code we can see that a field is added to the model with the addFieldO 
routine. The first argument is a string reference to the field and the second 
argument is a pointer to a Field. The GaugeField constructor takes four 
arguments. First is the plain text label of the field, followed by the LaTcX 
label. The third argument is the spin type of the field, in this case both fields 
are VectorSpin types. Lastly is a pointer to the GaugeGroup that this field is 
a mediator of. The routine getGaugeGroupO returns the GaugeGroup pointer 
referenced by the string. 

If one wanted to set a superpartner for the field this is done in the construc- 
tor. For example if we now wanted to add the fermionic superpartner to the B 
boson, this would be done by 

FermionSpin f ; 

addFieldC'Bino" , new GaugeFieldO'Bino" , "\\tilde{B>" , f, 

getGaugeGroupC'Ul") , 
getGaugeFieldC'B") ) ; 

The arguments are the same as before except we have added a reference to the 
superpartner of B, B. We don't need to give the B as an argument when we 
create B because the relationship is set for both of them when it is given to B. 
This is also necessary as you can't give a pointer to an object which you haven't 
created yet! 

Once the fields are created and added to the model, the terms given above 
are automatically entered into the effective action. 

2.3 Matter Fields 

We have now created the gauge fields. We need to create the remaining fields in 
the theory which interact with the gauge fields and each other. The class which 
defines these fields is MatterField. Again, these fields take a Spin class in order 
to define them. The implementation in Effective does not yet provide for a 
VectorSpin type of MatterField. The kinetic terms for the FermionSpin spin 
type of MatterField arc 

£Z (F) = -i^W^MBtyW (5) 

where the sums over the sets {A} and {B} are implicit and 

DfAUB} = S^ B %+i e m t% B A^ A ^. (6) 

te{G} 

In these equations {A} and {B} represent the set of indices from the fundamen- 
tal representation for all of the groups the MatterField interacts with. The sets 
{A'j} and {B^} are the sets of remaining indices when index i is removed. The 
sum in eqn. © is over all of the gauge groups, {G}, and t a ^. B . is the generator 
of group i, gi is its coupling and e$ is the charge of the field in the group. Aff 
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is the vector mediating the interaction for group i. Similarly the kinetic term 
for the ScalarSpin can be written as 

4L F(S) = (M A} ' {B V B 0^ {A},{B V B} ), (7) 



■'kin \ ^ 

where the covariant derivative is the same as in the FermionSpin case and the 
sum over the sets {A} and {B} are implicit. 

If a MatterField has a supcrpartner, there is an additional interaction which 

is 

l e{G} V2 

+c.c. (8) 

Here A ai is the gauge fermion of group i, (p and ip are supersymmetric partners, 
where ip is a scalar and i/j is a fermion. There is one additional term in a SUSY 
theory. This is 

-MFCS) _ V- V- f(j\ Ak ' {A ' k} t a " J 3 *'^ 

''-SUSY " l^i e i e 39k \yPi ) t A k B k l Pi 

t \^fc,{^' fe } B fc ,{A' fc }\ /n , 

Vj) f A k k B^J ) > ( Q ) 

where again the sum over dj, Ak,Bk and {A' k } is implicit. Gij is the set of 
groups field i and field j have in common. In order to include these terms, 
all scalars of the theory must be defined. These are added when the model 
initializes. If the user calls the routine Model: :noDterms(), then these terms 
will not be added, e.g. ElectroWeak: :noDterms(). This must be called in the 
constructor of the model. 

We now give an example of adding leptons and a SU{2) Higgs field to 
the electro-weak model. This is provided by the implementation of the void 
createMatterFields () routine. 

void ElectroWeak: : createMatterFields () { 
numeric half (1,2); 
ScalarSpin s; 
FermionSpin f ; 

addFieldO'l" , new MatterField ("1" , "Well", f, famsize, 

getGaugeGroup ( "Ul " ) , -half , 
getGaugeGroup("SU2") , 1)); 

addFieldC'eR" , new MatterField ("eR" , "e_R", f, famsize 

getGaugeGroup ("Ul") ,-1)) ; 

addFieldC'H" , new MatterField ("H" , "H" , s , 1 , getGaugeGroup ( "Ul " ) , 

half, getGaugeGroup ("SU2") ,1)) ; 

/ / Implement VEV code here 

> 



We see that the creation of a MatterField is similar to that of the GaugeField. 
The difference is that the MatterField can have several groups and a different 
charge under each group. If we look at the arguments for the MatterField 
constructor we see that the first three arguments are the same as for the 
GaugeField. These are followed by an integer representing the number of fam- 
ilies of the field, followed by pairs of GaugeGroup pointers and charges. The 
MatterField class allows each matter field to be a representation of no more 
than 4 gauge groups. If more than 4 groups are needed for a field, then a new 
implementation of MatterField must be made. 

Similar to the GaugeField the superpartner can be set by adding an ad- 
ditional argument to a MatterField pointer. This can be retrieved by a call 
to getMatterFieldO with the appropriate string as an argument. As in the 
GaugeField this superpartner needs to be passed only to the constructor of the 
second field of the pair. The appropriate relation is set for both fields. 

We can also see from the previous code segment that the fields I and e_R are 
defined as the electron fields (and all families), not the positron field. This can 
be seen as the charge of the en field is — 1, and the charge of the I field is — i 
under U(l) group and 1 under the SU{2) group. This gives the electron field a 
f (1)qed charge of -1. 

2.4 Vacuum Expectation Values 

One of the most important uses of the effective potential is its minimization 
to determine which, if any, of the fields in the model may develop vacuum 
expectation values. However, as it would be computationally prohibitive to do 
this simultaneously for all scalar fields, we use the Parameter object to specify 
which fields will be analyzed for VEVs. Once all the field content of the model 
is defined, the user can give some of the MatterFields a non-zero vacuum 
expectation value. This value can be given as a parameter of the model, whose 
value can later be changed to study the impact of the VEV on physical results. 

In the previous section we gave the first part of the implementation of the 
void ElectroWeak: : createMatterFields () routine. We now insert the VEV 
in order to complete this routine. The first step is to define a parameter which 
the user can use to modify the value of the VEV. This is achieved with the code 

Parameter upsilon = addParameter ("HiggsVev" , "Wupsilon" ,220.0, 

Parameter: :vev) ; 

This code creates a Parameter whose text name is HiggsVev and the LaTeX 
name is v. The default value of this parameter is 220.0. The last argument 
indicates that this parameter is a VEV. The function addParameter () adds this 
parameter to the model. The numeric value of all parameters is centrally stored 
in the model. This way a change to the value universally changes in all references 
to the parameter. The parameter can later be retrieved by calling Parameter 
Model: :getParam() with the string given as an argument. To retrieve the 
parameter defined above, the string HiggsVev must be passed. 
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There is also a routine numericfe Model: :getParameter() which takes a 
string as its argument. This routine returns the value (by reference) of the 
parameter. The value of this numeric object may be changed and the change 
will propagate to all of the parameters, but the numeric object should not be 
used when creating expressions. Doing so will put only the current value of 
the parameter into the expression. Future changes to the value will not change 
the expression created. Instead, if the user wants to create an expression with 
the parameter in it, they must create the expression with the Parameter object 
retrieved by the call to Model: :getParam(). 

Now the parameter which defines the VEV has been created, the field with 
the non-zero VEV can be defined. This is done by the call to the addVevO 
routine. In the electro-weak model we want to set the real part of the H 2 field 
to have a non-zero VEV. This is achieved by 

addVev ( "HiggsVev" , getField ( "H" ) , 1st (get Index ("H" , " SU2" ) ==2) , 
(upsilon+Model : :star)) ; 

The first argument is a string which identifies this VEV. Note that this does not 
need to be the same as the string which identifies the Parameter of the VEV, 
though it also need not be different. The second argument is a pointer to the 
field which the VEV is being set for. The third argument is a 1st object from 
GiNaC. This list specifies what substitutions to make on the Field multiplct 
to get the desired field. In this example the SU(2) index, retrieved by calling 
Model: :getlndex(), is set to 2. The last argument is the expression to replace 
the original field by. The object Model : : star represents the field in question. 
In this example the substitution 

K(H 2 ) v + K(H 2 ), (10) 

is made. A Parameter in Effective is always real. In order to replace the 
imaginary part of a field with a VEV, an additional argument, Imag, must be 
given to the addVevO routine. This would then make the substitution 

1(H 2 ) -» vi+l(H 2 ), (11) 

where vi is a new parameter specifying the imaginary part of the VEV. 

The last step is to tell the model that this parameter is a VEV, and not some 
other kind of parameter. This is important for the code as the VEV parameters 
are treated internally differently than other parameters. This is achieved by the 
call 

addVevParameter (upsilon) ; 

2.5 Default Behaviour of Field and Spin Classes 

Effective has many default behaviours built into the classes described above. 
These behaviours will be sufficient for most models, however, there are many 
models for which the user will need to implement their own classes. The 
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GaugeGroup, Spin and Field classes have been designed with enough flexi- 
bility to accomodate most modifications. Details of how one would make such 
modifications are reserved for scction lTTl Here wc present the default behaviour 
of the GaugeField, MatterField, ScalarSpin, FermionSpin and VectorSpin 
classes. 

The GaugeField class is designed to take one GaugeGroup and a Spin object. 
This will define the field multiplct of the given spin. The equations that dictate 
the kinetic terms where given in eqns. (Ill III . This allows one to try all sorts of 
things, not all of which will be renormalizable! For example, one could create 
a scalar gauge field not part of a supermultiplet, resulting in a kinetic term of 
the form 



In this equation the covariant derivative is given by eqn. Q and the indices are 
in the adjoint representation. Note that this is really a side-effect of the code. 
Effective has not been designed with such terms in mind. 

The MatterField class has been designed to take a family size, up to four 
GaugeGroups and charges under each group. This then generates the kinetic 
terms given in eqns. (|5I7|I . If a VectorSpin where to be passed to this class this 
would cause an error. The VectorSpin class has currently only been defined 
to work with GaugeField classes and subclasses. By implementing a new Spin 
subclass one could have a vector field with an arbitrary gauge representation. 

The Spin class defines several properties. The first one of importance is to 
specify how the field will be handled with respect to CP; whether the fields of a 
spin are complex or purely real. If they are complex the expressions are created 
so there is a unique expression for the real and for the imaginary part of a field. 
This implies 

f - m±fn. (13) 

As all fundamental terms in the expressions of Effective are real, this substi- 
tution allows the software to treat the field F as a complex field in terms of its 
real and imaginary parts. When one wants to probe the action for information 
on a field, they must therefore ask specifically about the real and the imaginary 
part of a field. The default behaviour of the ScalarSpin and FermionSpin 
classes is to treat the fields as complex, while the VectorSpin class treats the 
field as real. The division of the real and imaginary parts was intentional in 
order to study CP violating terms directly. A future extension will be to allow 
the user to decide whether to treat the basic objects in Effective as complex 
or not. 

The last relevant property of the Spin class is whether the spin type contains 
a Lorentz index or not. In Effective the Lorentz structure is treated explicitly, 
while the Dirac structure of the fermions is implicit. This means that the 
expressions of vectors have explicit Lorentz indices attached, while the fermions 
do not have spinor indices. A future extension will be to include the spinor 
indices on the fermions. 
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3 Interaction Terms 



The next step of the creation of the effective action of a model is to include 
non- kinetic terms. This includes terms such as the Higgs self interaction and 
the Yukawa couplings. In supersymmetric theories the superpotential replaces 
the need to implement some of these terms. 

3.1 How to add Desired Expressions 

To include the interaction terms in Effective the routine void addOtherTerms () 
must be implemented. As we have seen with the routines in the previous sec- 
tion, this routine is a virtual routine of the Model class. Thus the user's model 
is a subclass of Model and addOtherTerms () is a routine of their class. 

We now discuss the example of adding the Yukawa and Higgs self interaction 
terms to the electroweak model, defined by the class ElectroWeak. We will begin 
by showing the terms 



where there is an implicit sum over i. In the second term this sum is performed 
before the square 1 operation. This first term is given by 

Parameter mu = addParameter ("mu" , "\\mu" , 1.0); 
vector<idx*> indices = getField("H")->getIndices() ; 
ex H = getField("H")->expression() ; 
ex a = pow(mu,2)*H. conjugate () *H; 
add(Utils : : sumlndices (a, indices) . expandO ) ; 

The first line of code creates new Parameter object for the [i coupling. This 
is followed by a new object which requires explanation. 

3.1.1 Summation 

In Effective all of the implicit sums, like the ones in eqn. l|14f) . must be made 
explicit. In order to achieve this the user must tell the code which indices to be 
summed. Implicit in the creation of the indices is the values a particular index 
can take (except Lorentz indices, for which dimensionality is variable and need 
not be integer). 

The second line of code creates a list of all the idx (pointers) which the field 
"H" contains (not including any potential Lorentz indices). This list is then 
passed to the summation routine ex Utils: : sumlndicesO in the last line. 
This summation routine sums the first argument, a, over all of the indices in 
the second argument, indices. In this example the field H has only one index 
in the SU (2) fundamental representation. Explicitly the sum routine performs 




(14) 




(15) 
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where i is an SU (2) index. Notice that this summation is passed into the func- 
tion void add() . This tells the model to add the expression to the Lagrangian. 

3.1.2 Expansion 

One other note. The GiNaC engine may often keep terms grouped in multipli- 
cation, i.e. (x + y)(z+w), where in the Lagrangian, we want terms as individual 
products, i.e. xz + xw + yz + yw. The expandO routine ensures we have this 
expanded result. It is not necessary to call this command, the Effective li- 
brary will do the transformation automatically at a later stage. Performing the 
expand on the small expression above is much more efficient than waiting for 
the library to do it later. This is because the library will only do it once all the 
terms have been included and the VEVs set. Thus, it is recommended that this 
is done before it is added to the model. 

Now consider the second part of cqn. i|14|) . Here we must perform the 
summation before squaring the result. This is easily obtained from 

Parameter lambda = addParameter (" lambda" , "\lambda", 1.0); 
ex la = Utils :: sumlndices (H . conjugate () *H, indices) . expandO ; 
add(-lambda*pow(la,2) ) ; 

From the previous discussion all of the relevant pieces are already known. We 
create a new Parameter and compute the implicit sum. This sum is squared, 
multiplied by the coupling and added to the Lagrangian. 

3.1.3 Families 

The remaining term to include in the Lagrangian for the electroweak model is 
the lepton Yukawa coupling. This is given by 

£ YU k = >;>//,//"'; • c.r. (i6) 

We see that there is now a sum over families, i,j, as well as a sum over the 
SU (2) index a. These sums will be performed explicitly in the code. 

The code below will include the case for any number of families, with a 
special case for only one family. In this code the variable f amsize is a global 
integer which specifies the number of families. 

ex Ye ; 

if(famsize != 1) Ye = addFamilyMatrixC'Ye" , "{Y~e}", f amsize) ; 

else Ye = addParameter ( "Ye " , "{Y~e}", 1.0); 

idx i = Utils : :familylndex(0,f amsize) ; 

idx j = Utils :: familylndexCl ,f amsize) ; 

ex eR = getField("eR")->expression() 

ex 1 ; 

if(famsize != 1) 1 = 

getField("l")->expression() .conjugateO .subs(i==j) ; 
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else 1 = getField("l")->expression() . conjugate O ; 
indices = getField("l")->getIndices() ; 
ex b = -Ye*l*H*eR; 

if (f amsize != 1) indices. push_back (&j ) ; 

ex res = Utils :: sumlndices (b, indices) . expandO ; 

add(2*Utils: :real(res)) ; 

The coupling Y e can cither be a square matrix with dimensionality of the num- 
ber of families or just a simple Parameter if there is only one family. The 
variables i and j are indices in the "family" space. This is the same space that 
the matrix Y e is defined in. The routine addFamilyMatrixO creates a matrix 
which is f amsizexf amsize. Each element of the matrix is associated with a 
unique Parameter with name Yei j where i andj are replaced by the particular 
value of interest, i.e. Yel2. The first argument is the string by which the matrix 
is stored for future retrieval. This argument also doubles as the value printed 
for non-LaTeX output. 

Utils: :familylndex(0,f amsize) is a utility routine in Effective to re- 
trieve index 0, from a predefined list of indices, with dimensionality f amsize. 
Such predefined lists exist for all types of indices (e.g. SU(2), family, Lorentz, 
etc.) so that indices can be matched and replaced when creating expressions. 
The f amilylndex(i , s) routine will return the ith index from the list with 
family dimension s. When a field is created, it's family index is always the 0th 
element of that list (the same applies to the group indices). When the family 
matrix is created, it has two indices, the 0th and the 1st. Thus we retrieve the 
0th and the 1st and store them in the variables i and j , respectively, for later 
use. 

3.1.4 Expression Substitution 

The next line of interest is when the left handed lepton expression is retrieved. 
In the case that f amsize != 1 we see the extra command subs(i==j). This 
is a very powerful, and useful, function in GiNaC. This instruction takes the 
expression it is called on (in this case the full complex expression of €) and 
substitutes all occurrences of i with j . Thus the sum over i does not affect £j 
and in the sum over j, em, is unaffected. In both summations does change. 
We can see this summation in the second to last line. We see in the line before 
that the family index j is added to the list of summation indices. We must 
remember that when we retrieved the indices from the left-handed lepton field 
it only contains one family index, i. Thus to do the double summation, we must 
add j to our list. Explicitly, this summation is 



where a is the SU(2) index. The function Utils : :real() in the last line returns 
only the real component of the expression. The factor of 2 is there since X + 
c.c. = 2Re(X). 




(17) 
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4 Superpotential 



The most general set of renormalizablc SUSY interactions are given by 



Amp = —wVMj+urwf + cc, (18) 



where 



W = ^M ij (pitpj + ^y ijk (piipjV>k, (19) 
W 13 = , (20) 



J 

sw 

W l = i-. (21) 

difi 

In these equations the fields {ipi,ipi) form a supcrmultiplet. This means that 
M y is the mass matrix of the fcrmion fields and is the Yukawa coupling of 
a scalar, tp k to fermions ipi and ipj. Technically, the superpotential is defined 
in terms of supermultiplets. In Effective, this is not the case. For the N=l 
supcrsymmctric case, we can implement the superpotential as a function of 
the scalar fields. A future enhancement of the code will change this to a true 
definition in terms of supermultiplets. 



4.1 Implementation of MSSM Superpotential 

We now give an example of the MSSM superpotential. Just as the previous 
section, we will rely on making explicit the implicit summations that occur, 
for example, in eqn. 1)18(1 . The superpotential is implemented by defining the 
function ex superPotential () in user's model subclass. Note that this func- 
tion now returns an expression, unlike the addOtherTerms () routine, the user 
must not call the Model: :add() routine on terms in the superpotential. We 
will implement the MSSM superpotential 

Wmssm = e ab (Yf J dH?Q b -Y%uH2Q b + Yf J eH?£ b )+LiH 1 H 2 . (22) 

In fact we will only show the implementation of the YZ term. The process of 
implementing the other terms is straightforward. Also note that, as mentioned 
before, the superpotential is defined in terms of supermultiplets as is eqn. (1221) . 
The implementation will only be defined in terms of the scalar fields of the 
supermultiplets . 

ex Ye = addParameter(Ye,Y_e, 1 .0) ; 
ex superPot = 0; 
vector<idx*> sumlndex; 

Matterlndex a = getGaugeGroup ("SU2")->matter Index (0) ; 
Matterlndex b = getGaugeGroup ( " SU2 " ) ->matter Index ( 1 ) ; 
idx i = Utils : :f amilylndex(0,f amsize) ; 
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idx j = Utils : : f amilylndexCl ,f amsize) ; 

ex epsab = epsilon_tensor (a,b) ; 

ex hi = getField("Hl")->expression() ; 

ex h2 = getField("H2")->expression() ; 

ex 1 = getField("sleptonL")->expression() .subs(i==j) ; 

ex eR = getField( "sleptonR" ) ->expression() ; 

sumlndex = getField("sleptonL")->getIndices() ; 

sumlndex. push_back(&b) ; 

sumlndex. push_back(&j ) ; 

ex temp = Ye*epsi j*hl* . subs (a==b) *eR; 

superPot += Utils :: sumlndices (temp , sumlndex) . expandO ; 
// other terms go here. . . 
return superPot ; 

As before we retrieve the index in the fundamental representation of SU(2) 
(referred to as the Matterlndex) from a predefined list. We create the epsilon 
tensor in this space and the term of eqn. (1221) can then be directly imple- 
mented as shown. It has been assumed for this code that the fields HI, H2, 
sleptonL and sleptonR have been defined. 

5 Effective Potential 

The effective potential is one of the main components of Effective. This 
can be generated at tree-level or at one-loop in Effective. We give a brief 
review of the generation of the effective potential in the appendix. The result 
in the appendix can be extended to all fields to read, in the DR renormalization 
scheme, 



Here the mass matrix M is the tree-level mass matrix for a set of particles. The 
"supcrtracc" , STr[/(X)] is defined as 



where Sj is the spin of the ith particle. This "supertrace" is just the spin 
weighted trace of the mass matrices. 

To find the value of the VEVs, the effective potential can be minimized as a 
function of the VEVs. Note that the conventional approach, to find those VEVs 
which set to zero the tadpole diagrams, is equivalent. The tadpole terms are 
given by 




(23) 




(24) 




(25) 
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for all ifi with a non-zero VEV. Thus to solve 

dV eS 



0, 



minimizes the potential and is equivalent to solving for the zero of the tadpole 
contributions. 



5.1 Effective Potential in Effective 

We now turn to routines to access the effective potential in Effective. The 
effective potential can be accessed with the ex Model: :potential() routine. 
This routine takes an Approximation : : Approximations flag to specify whether 
the potential should be evaluated at tree-level or at one-loop. The default 
behaviour (if no Approximation: : Approximations flag is given) is to return 
the tree-level value. At tree- level, this function returns an analytic result. At 
one-loop, it is returned numerically at the point in field-space given by the 
current VEVs. It is also worth noting that the potential is actually returned 
with the value of the potential when all VEVs are zero is subtracted from it, 
i.e. the difference between the value at the current location in field-space and 
the value at the origin. 

To determine the "natural" values of the VEVs the effective potential needs 
to be minimized over a set of parameters. This can be achieved by a call to 
the Numerics: : extremizePotentialO routine. This routine takes a list of 
Parameters to minimize the potential over. It also takes an Approximation- 
: : Approximations flag to indicate what level of approximation of the potential 
to use during the minimization. This routine uses the direction set (or Powell's) 
method in multidimensions |11| to minimize the potential. If this method fails, 
the original values of the parameters are restored. 

There is also a routine, exvector Model: : tadpoles () which returns a list 
of the values of the tadpoles for the current values of the Parameters. This 
routine also takes an Approximation: : Approximations flag. If none is given 
the default behaviour is to return the tree- level result. 

Similar to the potential, there is a routine which can scan a parameter set 
and find where all all tadpole diagrams are zero. This routine can also use tree- 
level or one-loop tadpoles. The routine is Numerics: : solveZeroTadpoles () . 
This routine takes a list of parameters to scan over and an approximation to 
use. This routine also takes a boolean flag which, when true, will save the 
values of the parameters passed to the routine and if the routine fails, it will 
restore the values. If false is passed, the values of the parameters after a failed 
call are unpredictable. This routine uses the Newton-Raphson method of root 
finding |llj to numerically determine the values of the Parameters that make 
all tadpoles zero. 

Both the extremizePotentialO and the solveZeroTadpoles () routines 
have built in error handling. This will print to the cerr stream the cause of any 
failed calls. These messages are useful to explain odd behaviour of a program 
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after a failed call. An error logging system will be implemented in a future 
update so all messages can be stored in a file. 

We now give the example of calling these routines with the ElectroWeak 
model that we partially defined in the previous sections. The full definition of 
this class can be found in the appendix. 

vector<numeric*> list; 

list . push_back(&(ew .getParameter ( "HiggsVev") ) ) ; 
ex pot = Numerics :: extremizePotential(&ew, list) ; 
Numerics : : solveZeroTadpoles (&ew, list ,true , 

Approximation: :DneLoop) ; 

In this code the variable ew is an instance of the ElectroWeak class. We see 
here that the tree-level potential is minimized in the third line and the value of 
that minimized potential is stored in the pot variable. The fourth line then is 
an example of finding the value of the Higgs VEV which gives a zero one-loop 
tadpole. 



6 Mass Matrices 

We now turn to the mass matrices. These are derived from the Lagrangian by 

(26) 

Wk=<Vk>} 



OipiOipj 



where represents any field and < tpk > is the expectation value of field tfk- 
Mij contains the mass-squared matrix for scalars and vectors, but only the mass 
matrix for fermions. The plus or minus term is due to the fact that the mass 
term for vector bosons have a positive sign in the Lagrangian, but for fermions 
and scalars it has a negative sign. 

Once we have evaluated all of the elements i, j of the mass matrix we must 
diagonalize it. The elements in the Lagrangian are the interaction eigenstates 
of the fields. The masses correspond to the mass eigenstates. Diagonalizing the 
mass matrix will give us a rotation matrix to mix the interaction states and 
give the mass states. The masses of the mass states are then the values of the 
diagonalizcd matrix. 



6.1 Tree Level Mass Matrices 

At tree level the mass matrix generation and diagonalization is straightforward. 
Employing eqn. I|26(l we can create large matrices with all of the tree level 
terms. We can then divide the large matrix into block diagonal parts. The 
diagonalization procedure of the large matrix will give the same results as the 
diagonalization of the smaller matrices, but is much more efficient. Since all 
terms in Effective represent real fields, we have real mass matrices. We can 
diagonalize the matrices to get 

Ma = U lk D kk Ul 3 . (27) 
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The Dkk matrix is a diagonal matrix and the Uij matrix is a unitary matrix 
which contains the rotations. From this one finds 

»u. = UlM l3 U 3k , 

and in the Lagrangian this is 

$M im = (U^ i ) T D kk (U t kj( p j ) = (^) T D kk (^). (29) 

This allows us to interpret U^ipi as the mass eigenstate <f>jf , which implies UZ 
is the mixing angle between interaction state ipi and mass state ip¥ . 

In Effective the classes Mass and MixingAngle provide an interface to 
this process. These objects are GiNaC objects which means they can be di- 
rectly used in analytic expressions. When one evaluates these, the appropriate 
diagonalization is performed and the numerical element is returned. 

A small discussion is needed about fermion masses. For the vector and scalar 
masses the diagonal matrix contains the mass squared. A negative mass-squared 
represents a tachyon and in turn has some implications to the parameters and 
structure of the theory. For fermions, however, a negative diagonal element is a 
negative mass. The mass-squared is still positive so it is not a tachyon. Instead, 
an appropriate shift of phase is required. Such a shift of phase converts the mass 
of the physical state from negative to positive. In Effective, such a rotation 
is performed internally automatically. Thus, fermionic mass states always have 
positive mass. This can be seen by shifting the physical mass state by 

This shift leads to 

my M y M = to (V M ) («V M ) = -mcp' M <p' M . (31) 

As we can see, the mass can be shifted from negative to positive simply by an 
appropriate phase shift. This shift amounts to reinterpreting the mass eigenstate 
to include the rotation by U and the phase shift. 

6.2 One-Loop Mass Matrices 

When we move to the one-loop corrections to the mass matrices things get 
slightly more complicated. Now our Lagrangian couplings are not the bare 
parameters of the theory, but instead renormalized ones. 
An element of the renormalized Lagrangian would read 

C = Zid^id^i-^ZVMijZ^Zy 2 ^, (32) 

where Z^ 2 ipi is the renormalized field <pm, and Z^Mij is the renormalized 
mass, Mftij. The diagonalization and mixing of states proceeds in the same 
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(28) 



(30) 



manner as before. The difficulty now lies in automatically computing Mmj 
from the tree-level Lagrangian and imposing the renormalization conditions. 

We now define the two point Green functions T^(p 2 ) that arc included in 
Effective at one- loop. At one-loop there are two topologies that can enter 
the two point Green functions. These are shown in figure ^ We will refer to 
figure ^a, as a three-point diagram (as the couplings are three-point couplings), 
and figure ^ as a four-point diagram. The three-point diagrams are functions 
of the masses of the two internal lines while the four-point diagrams are only 
functions of the mass of the one internal line. All diagrams are renormalized at 
a scale \i. 




(a) (b) 

Figure 1: The two topologies for one- loop two point Green functions. 

We can now define the values of these individual diagrams for each combi- 
nation of spins that can arise. In Effective, certain assumptions about the 
Lorentz structure of the couplings is made. In models where these assumptions 
break down, the one-loop corrections of Effective will be wrong. We have 
also implemented the contributions in the Feynman gauge. This means we also 
must include the appropriate ghost contributions. We will now discuss the con- 
tributions to three sets of diagrams: scalar-scalar, fermion-fermion and vector- 
vector. All of the corrections are expressed in terms of Passarino-Veltman ^2] 
functions in d dimensions. A list of the Passarino-Veltman functions and the 
one-loop mass corrections are given in the appendix. It is extremely important 
to note that by including the complete set of one-loop diagrams for arbitrary 
couplings and spins we remain model- independent. However, we restrict our- 
selves to one-loop diagram topologies with up to four-point interactions. To 
include a model which contains higher-than-four-point interactions one would 
have to include some more integrals. 
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6.3 Renormalization Prescription 

We now turn to the mechanism by which the two-point Green functions are used 
to provide the one-loop mass corrections in Effective. In Effective the MS 
renormalization prescription is used. This means that the terms with (e) -1 
from the Passarino-Veltman (PV) functions are absorbed into the definition of 
the bare parameters. In the current version the PV functions are only defined 
in terms of their finite contributions. Thus, even though the Green functions 
arc defined in d dimensions, using d = 4 — 2e will not properly give finite 
contributions from terms like e-Bo(p 2 , m 2 , fin 2 ,] H 2 )- This is equivalent to using 
the DR scheme, where the momentum are taken in d dimensions, but the vectors 
and Dirac 7 matrices are treated in 4 dimensions. Using the DR scheme we 
define the one-loop renormalizcd Green functions 

rgV) = rLl( P 2 ) + rfl op b 2 ). (33) 

This is equivalent to using counterterms in the Lagrangian. For example the 
tree-level Green function for scalar fields is given by 

Now the one-loop term is of the form 

so the renormalized term is 

rgV) oc (l + A)[9 M ^-(mo-fl) v V (34) 

If one uses the on-shell prescription we require the pole of the propagator to be 
equal to the physical mass. This is 

itV) „ = 0, (35) 



R 



01W 



dp 2 



= 1. (36) 



This is equivalent to requiring that the renormalized Lagrangian takes the form 

£r = d^ipRd^ifR + m%ip R tp R . 

We consider the case where there is mixing between fields; the on-shell renor- 
malization condition is equivalent to requiring the denominator of the propaga- 
tor to vanish. Thus the solution p 2 — m 2 R gives 

Dct [%(p 2 - m 2 , y ) + II(p%-] = 0. (37) 
For fermion fields this takes the form 

Dct [8 l3 (jp - mo,*,-) + £(i*)y] = 0. (38) 
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where II(p 2 ) and E(/£») are the self-energy diagrams given in sections IE.1IE.3I 
and rriQ ij is the tree-level mass squared. 

There is an additional complication that arises because the Green functions 
and renormalization conditions are defined for the mass eigenstates. This means 
we must find the mass eigenstates of the tree-level action first. We then renor- 
malizc the mass eigenstates by solving either eqn. 11370 or (|38[) . This will lead 
to a new rotation matrix which rotates the tree-level mass eigenstates into the 
rcnormalizcd mass eigenstates. The mixing angles between the interaction eigen- 
states and the renormalized mass eigenstates are then given by two rotations; 
the rotation from the interaction states to the tree-level mass states followed by 
a rotation from the tree-level mass states to the renormalized mass state. 

6.4 Default One-Loop Mass Corrections 

Effective provides two classes, Mass and MixingAngle. which provide alge- 
braic objects that can be used and manipulated in expressions. Both of these 
classes require an object which instructs them what level of approximation to 
compute the values at. By default, if nothing is provided, the correction is given 
by the MassCorrection : :TreeLevel class. As expected this class will simply 
diagonalize the tree level mass matrix and return the value desired (mass or 
mixing angle). We now discuss the three different one-loop corrections that 
have been implemented in Effective. Again, a user can implement their own 
approximation and renormalization conditions. Discussion of this extension is 
given in section ITT1 

Effective provides three methods to generate one-loop mass corrections. 
All of the corrections arc an implementation of the on-shcll conditions. If a user 
wishes to implement alternate conditions, this can be done by implementing 
their own MassCorrections sub-class. Two of the provided classes return the 
same one-loop mass, but different mixing angles. 

We begin with the approximate method DneLoopMassApprox. This class 
approximates the one-loop masses and provides only tree level mixing angles. 
This is done by computing only the Green functions for the diagonal terms, i.e. 
Tln(p ), This is computed with the tree level mass squared as the argument for 
the momentum squared. The mass squared is then 

mf =ml l -Ii{ml l ) l , (39) 

where II(p 2 ) are the self-energy diagrams given in sections IE. HE. 31 and m 2 , i is 
the tree-level mass squared. For fermions this reads 

mi = mo,i - E(mo,i)«. (40) 

The other methods solve eqn. (|37|) or l|38|l using the bisection method 
The MassCorrection: :DneLoopMass class returns the one-loop mass but only 
gives the tree-level mixing angles. The MassCorrection: : OneLoop class returns 
both the one-loop mass and mixing angle. 
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The implementation of the bisection method has five parameters which can 
be adjusted by the user to improve numerical stability and convergence. The 
method first brackets the solution. As an initial guess the starting point for 
the bracketing is given by the tree-level mass plus-or-minus 1%. In the case 
that the tree-level mass is zero, the bracket is given by ±10 -9 . Also, for effi- 
ciency, as many zero mass fields are massless by construction, a quick check is 
performed. If the determinant from eqn. I|37() or i|38|) is less than Numerics- 
: :MassRoundError it is assumed that this mass is exactly zero. The default 
value of MassRoundError is 10~ 4 . 

If the mass is not zero and the initial bracket does not bracket the solution, 
than the bracket is expanded until the solution is contained. If the expansion 
reaches the maximum number of iterations, Numerics: :MassMaxIterations, 
than the method fails and the tree-level mass is returned and a failure message 
is printed. Each iteration the bracket grows by FAx where Ax is the current 
size of the bracket and F is the parameter Numerics : : MassFactor. The default 
value is 0.6. 

Once the solution is bracketed, the bisection method is iterated until the 
solution is found, within Numerics: : MassAccuracy times the tree-level mass 
(if mass is zero then the accuracy is 10 -9 ). The default value is 10 -4 , which 
means the solution is found within 0.01% of the value of the tree-level mass. If 
the method iterates Numerics: : MassScanlterations times and no solution is 
found, the method prints a failure message and returns the last value used. 

7 Renormalization Group Equations 

In this initial release, Effective does not automatically generate the renor- 
malization group equations (RGE). The library does, however, provide a class 
to handle RGEs and evolve the parameters according to those equations. It is 
planned that in a future release, the one-loop RGEs will be automatically gener- 
ated for an arbitrary model according to one or more renormalization schemes. 

This section will detail how one implements the RGEs of a model. The 
user is free to implement these according to any renormalization procedure. It 
must be noted that the default behaviour of the one-loop mass corrections must 
be taken into account when implementing these RGEs. If one wishes to use a 
different renormalization scheme, it may also be necessary to implement a new 
set of one- loop mass corrections in order to be consistent. 

7.1 Defining the Equations 

The class that handles the RGEs is the class RGE. This class is created by the 
constructor RGE(Model*); this constructor ties the instance of the RGE class to 
a particular model. Upon creation, the RGE class creates a list of the parameters 
in the Model and associates with each parameter an expression. 

The user can supply the expression for the function of any of the pa- 
rameters to any order desired. This can be provided by a call to the routine 
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RGE: :setBeta(). This routine takes a Parameter x and the expression for (3 X . 
This routine saves the expression, in analytic form, so that it can evolve the 
rcnormalization scale and adjust the parameter x appropriately. An example of 
defining and setting the appropriate /3 function will be given now. 

If we consider the one-loop (3 function for the gaugino mass coupling M\ in 
the MSSM model. This is given by 



R Ug ' 2Ml UU 



where g' is the £7(1) coupling. This can be added to an RGE object by 
RGE rge (&ew) ; 

ex gl = ew.getGaugeGroup("Ul")->coupling() ; 
Parameter Ml = ew.getParamC'Ml") ; 
rge->setBeta(Ml , ll*gl*gl*Ml/(8*Pi*Pi) ) ; 

We can now see how easy it is to implement the RGEs of a model, once they 
have been calculated. This procedure can be used to redefine the gauge coupling 
(3 functions as well as all other couplings of the theory. Once the full set of (3 
functions have been defined, we can then evolve between different scales. 



7.2 Example of automatic RGE generation 

The currect version of Effective includes a prototypical example of automatic 
RGE generation. When the object is created the (3 functions of the gauge 
couplings are created automatically at one-loop. The one-loop (3 function is 

Here the sum over i is the sum over fermions. Ci jS is the charge of fermion i 
in group g. The factor Cpi/Ai represents the fact that the fermion could be a 
gaugino (in supersymmetry) or a regular fermion. If it is a gaugino it is in the 
adjoint representation and thus a factor of Ca, otherwise the factor is Cf- The 
sum on j is over all scalar fields with the same factors as in the fermionic case. 

It is important to note that this equation should also include 0(fj, — rm) 
where \i is the current renormalization scale and rrii is the mass of particle i. 
This would correctly implement the mass effects in the (3 function. The other 
couplings of a model do not yet have a (3 function generated automatically. A 
future improvement is to include the mass effects into the gauge couplings and 
to provide the full one-loop RGE for an arbitrary model. 



7.3 Evolving Between Scales 

One of the powerful uses of the RGEs is to be able to define the parameters at one 
rcnormalization scale, but use them to calculate at another. This is especially 
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important in SUSY models where one wants to define boundary conditions at 
a high scale, i.e. Mpi anc k. These boundary conditions are usually used to unify 
several parameters to one value at the high scale, thus reducing the size of the 
independent parameter set. 

In Effective the RGEs can be used to evolve the parameters between 
different scales. The current scale of the model is given by a Parameter which 
is labeled as "renormScale". This scale can be changed to a different scale and 
the parameters of the model are then evolved to that scale by the RGEs. This is 
achieved by the routine RGE : : evolve () . This takes a numeric value of the new 
scale and uses the Runge-Carp-Kutta numerical method to iteratively apply 
the differential equations of the RGE to the parameters so they are properly 
evolved to the new scale. 

The class RGE also provides several routines which allow the user to simply 
define the desired values for the parameters at a particular scale. Then when the 
parameters are evolved to that scale, a simple call will force all the parameters 
to take the preset values. This is very useful when different parameters arc 
defined at different scales and a consistent result is desired. 

For example, consider parameters a and b. The j3 functions of these param- 
eters are function of both a and b. If we know a should have a specific value 
ao at scale fix and b should have the value bo at scale /^2, we must determine 
what a is at \ii and what b is at [i\ by an iterative approach. We must make 
some educated guess for and evolve to fj,2- Our guess will be wrong so our 

b(ii2) is not equal to bo- If we set it equal to bo and evolve to \i\ chances are our 
a(/ii) is not equal to ao- We then set a to ao and this procedure can be iterated 
until the solutions converge, or we decide they are not converging. If they don't 
converge we must assume that the boundary conditions cannot simultaneously 
by fulfilled. 

Such a procedure can be implemented in Effective. We will not refer 
to a specific model in the next code block, but instead show how the routines 
RGE: : initialConditionO , RGE: : applylnitialO and RGE : : evolve () can be 
used to implement the above example. 

double delta = 0.1; 
double mul = 90 . ; 
double mu2 = 120 . ; 
double aO = 5 . ; 
double bO = 7 . ; 

Parameter a = 'model'->getParameter("a") ; 

Parameter b = 'model'->getParameter("b") ; 

rge . initialCondition(a, 5 . ,mul) ; 

rge . initialCondition(b,7 . ,mu2) ; 

bool consistent = false; 

int max_tries = 50; 

int tries = 0; 

' model ' ->getParameter ( "renormScale " ) =mul ; 
b = 1.; 
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while (! consistent && tries < max_tries) { 
rge->evolve (mu2) ; 

if ( (b+delta) > bO && (b-delta) < bO) consistent = true; 

rge->applylnitial(mu2,3. ) ; 

rge->evolve (mul) ; 

rge->applylnitial (mul , 3 . ) ; 

tries++; 

} 

We can see from this code that the routine RGE: : initialConditionO allows 
us to set the value of a parameter at a scale. These initial conditions can then 
be applied later by a call to RGE: : apply Initial () . We see that this routine 
takes a scale as an argument. All Parameters that were given an initial value 
are checked. If the scale that the initial conditions were defined at is within 
S of the given scale, the initial value is applied. S is the second argument to 
RGE: : applylnitial () . If this is not provided the default value is 3. 

Notice in this code that we have not designated any particular form to the 
/3 a and Pb functions. They must be defined for the code to work, but their form 
does not impact the algorithm above. It only dictates if consistent solutions can 
be found. 

It is also important to note that the /? functions are stored analytically. 
They can be printed in LaTeX format or in plain text by calling the routine 
RGE: : print (). This routine takes a stream and prints the (3 functions to it. 
This can be useful when debugging your definitions of the /3 functions. 

8 The examination of arbitrary observables us- 
ing Effective 

We have now discussed how to define the particle content of a model. We have 
enumerated the terms that this definition automatically supplies to the La- 
grangian and explained how to include additional interaction terms and vacuum- 
expectation-values. We have seen how the effective potential and tadpoles can 
be accessed for this model both at tree-level and one-loop and how the potential 
can be minimized, and the tadpoles set to zero by numerical means. We have 
shown how the masses and mixing angles of the fields can be accessed and how 
the one-loop corrections arc defined. Lastly, we have discussed the renormaliza- 
tion group equations and how they can be defined and used to give a consistent 
set of values at all scales. 

The purpose of this library is to provide the user with a tool to study many 
different aspects of their model, yet we have not explained how to use effec- 
tive to calculate physical observables other than the masses and mixing angles. 
Effective provides an abstract class Diagram that can be used to compute 
physical observables deriving couplings and parameters from the model. The 
Diagram class is not the only way that physically relevant information can be 
drawn out of Effective. A creative user may be able to find interesting and 
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exciting uses for this library well beyond the scope of this article or the authors' 
imaginations! 

As mentioned, the feature built into Effective which makes it easy to 
study arbitrary properties of a a model is the Diagram class. The user specifics 
the expression corresponding to some diagram, and then effective automatically 
iterates through all appropriate fields on internal lines, and all appropriate cou- 
plings (with the right spin and derivative structure) at each vertex. The class is 
used internally by Effective with the Passarino-Veltman functions to obtain 
masses and mixing angles at one-loop, so the user can use these as examples 
when creating their own diagrams. 

The class is an abstract class; some of the routines of the class must be filled 
in by the user in a class which is derived from Diagram. The main interface to the 
class is through the method evaluate (). This routine will call the abstracted 
routines appropriately, building up a summed value for the diagram as it loops 
through all n point couplings and fields on internal lines in a model by calling 
the abstract function calculate () for each coupling to determine its value. 

The routines that the user must define in the deriving class are calculate () , 
functionO. The calculate () routine is called by the evaluate () routine. 
On input, an n point coupling is provided, the routine should check that the 
coupling is appropriate to the diagram being defined, ft is the responsibility of 
the class which inherits Diagram to specify which couplings are appropriate to 
the diagram. For example in the FourPtLoop class the coupling must correspond 
to the desired two external fields and have the same internal field. 

In the current version of Effective the sums over fields on internal propa- 
gators must be carried explicitly in the user-written calculate () routine; those 
implementing new diagrams should copy over the appropriate loop statements. 
In a later version we hope to refactor this into the automatic parts of the Diagram 
base class. 

The Diagram class provides a few routines which can be helpful when deter- 
mining if the given coupling matches the desired criteria. The routine Diagram- 
: :makeList() will take the expression for the fields of a coupling and return 
a list; each element contains a flag indicating if the field was accompanied by 
a derivative, and the field itself. The routine Diagram: :find() can be used 
to determine if a field with a particular derivative flag is in the list returned 
by makeListO. If it is, the routine Diagram: :remove() can be used to re- 
move the matching item. When the routine has decided whether the coupling 
is appropriate, it should call functionO. 

functionO is intended to be the value of the diagram for a particular choice 
of vertex and spins of internal fields. This idea can be seen in the mass correc- 
tions of section [!)] In those diagrams, the function is defined for a particular 
choice of the spin of the intermediate particles. Then this function depends only 
on the p 2 of the Green's function and the masses of the intermediate fields. 

The best way to understand how the Diagram class is intended to be used 
is by a demonstration. This is too long to include in this article, and is instead 
deferred to a tutorial page on the website mentioned in the first section. 
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9 Practicalities 



In this section we will discuss some practical issues with Effective. We will 
describe routines which reduce processor overhead by saving and loading the 
system's internal representation of a model: the coupling database and the pa- 
rameter values. We will also discuss the rudamentery command line interface 
and how to achieve the same effects without relying on the command line inter- 
face. 

Before we discuss these uses we must discuss one essential routine, Model- 
: : initialize () . This routine must be run before any physics is computed. 
This routine takes no arguments and specifics to the model that all the infor- 
mation needed to generate the Lagrangian and mass matrices is present. Once 
this is run the user may proceed to study their model as they wish. 

Of course the purpose of this library is to provide the user with a tool to 
study many different aspects of their model. To this end, the discussions in this 
section and the next do not contain all possible uses. A creative user may be 
able to find interesting and exciting uses for this library well beyond the scope 
of this article. 

9.1 Saving and Loading Couplings 

Effective generates internally a coupling database from the action for use in 
calculating observables and mixing angles. This can grow to be quite large. For 
large models the generation of this database can take of order of 30 minutes 
on a modern computer. The results of this generation can be saved to a file, 
however, and on future runs this can be read in just a few seconds. We discuss 
here how to specify whether to generate the couplings or read them. We also 
discuss when the database must be generated. 

The Model class has a variable Model: : couplingsFromScratch which is a 
static member of the class . If this is set to true before the model is initialized, 
then the couplings will be generated directly from the Lagrangian. If this is 
false then the couplings will attempt to be loaded from a file. The default 
value of this variable is false. 

If one wishes to load the couplings from a file, the filename must be specified 
before initializing the model. This is done by calling the Model: : couplings () 
routine. This takes the filename as an argument. The same routine is used to 
specify a filename to save a file to. If the static variable Model : : saveCouplings 
is true, then the model will automatically save the file when the program com- 
pletes. These features are illustrated by the following code. 

ElectroWeak ew; 

Model :: couplingsFromScratch = true; 
Model :: saveCouplings = true; 
ew. couplings ("ew. gar") ; 
ew. initializeO ; 
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These features are also accessible through the command line interface. A simple 
routine Model: : readCommandLine () has been written that accepts the flags 
-r, -s and -h. The -r flag is used to specify that the couplings should be 
regenerated. The -s flag specifies that the couplings should be saved to the 
file and the -h flag is a help command which prints all options. This is a very 
simple interface but it allows the user to run the code with different behaviours 
without having to recompile. 

If we rewrite the above code as 

ElectroWeak ew; 

Model: : readCommandLine (argc,argv,feew) ; 
ew. couplings ("ew. gar") ; 
ew. initializeO ; 

we can now run the executable in several different variants. If we wish to load 
the couplings, we provide no flags. If we want to save the couplings we give the 
-s flag and is we want to recompute the couplings, we give the -r flag. It is 
obvious that most times, the -r and -s flags will accompany each other. 

It is also important for the user to know when they should recompute the 
couplings. The couplings must be recomputed if the Lagrangian is modified at 
all. For example, one may wish to begin studying a model with only one family 
of fcrmions. They may wish to then include 3 families of fcrmions and repeat 
their studies. Once they include the additional terms in the Lagrangian they 
must recompute the couplings. Failure to do this will mean that they will only 
load the couplings for their one family model and their studies will be wrong. 

9.2 Modifying, Saving and Loading Parameters 

One of the useful features of Effective is the ability to keep the expressions in 
analytic form and to perform numeric operations on these expressions. This is 
able to be done because all Parameters are simultaneously an algebraic object 
and a numeric value. The object is kept in all expressions until the evalf () 
function is called. At that point, the algebraic object is replaced by the numeric 
value of the parameter. 

This duplicity of the Parameter object allows the user to create all their 
expressions, derived from the Lagrangian, and very quickly access the numeric 
value of the expression. Changing the value of a Parameter globally changes 
the value all expressions. When evalf () 'd an expression will return its numeric 
value with the changed value for the parameter. For example, changing the value 
of a VEV will simultaneously change the value of the effective potential and the 
masses of the particles. 

It is important to note that though the undiagonalizcd mass matrix is au- 
tomatically changed to reflect the new parameter value, the diagonalized mass 
matrix may not be. If the mass matrix is larger than 2x2, then the diagonaliza- 
tion is a numeric routine. This means it must be recomputed to update the mass 
of a particle. Not to worry though, a simple call to the Model : : resetMasses () 
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routine will instruct the library to rediagonalize all matrices which arc diago- 
nalized numerically. 

To illustrate the power of this feature, we will give an example of how to 
evaluate the one-loop effective potential as a function of the VEV. Considering 
again the electro-weak model the following code scans the VEV and evaluates 
the one-loop effective potential. 

Parameter vev = ew.getParamO'HiggsVev") ; 
double v; 

for(v = -246.; v<=246 . ; v+=5 . ) { 
vev = v; 

ew . resetMasses () ; 
cout « v « "\t" 

<< ew. potential (Approximation: :DneLoop) . evalf () 

« endl; 

} 

We see in this code that to set the value of a Parameter, wc treat it like we 
would a normal variable. A simple call to the = operator sets the numeric value 
of the VEV. This is then propagated to all the masses (used to compute the one- 
loop potential) and the tree- level potential expression. Simply calling evalf () 
on the potential replaces all the Parameters with their numeric value. 

There is also a simple input/output mechanism for the values of the Para- 
meters of a model. This saves or loads the values from a tab delimited file. 
This is achieved by the routines saveParameters () or loadParameters () of 
the class Model. These routines take the stream to read or write to. The 
loadParameters () routine will print an error message if the file does not have 
the correct structure or one of the Parameters has the wrong label. We give an 
example of the one-family electro- weak input file. 

renormScale 91.0 
HiggsVev 246.0 
SU2 0.653089 
Ul 0.3550 
Ye 1.3e-5 
lambda 0.182513 
mu 105.095 

We notice that the first line of the file is the renormalization scale. This is also 
the scale for all of the parameters in this file. We saw in section [7| a possible 
treatment for parameters defined at different scales, these simple input/output 
routines are insufficient for input at multiple scales. 

It is possible to save the parameters in any format desired, for example 
according to the SUSY Les Houches Accord ^3 (LHA). This simply requires 
writing new code to print and read the format appropriately. The Les Houches 
Accord format has not been implemented in this version of Effective, but the 
SUSY LHA format is a planned upgrade. 
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10 Example: One Family Electro- Weak Model 



We now turn to a concrete example, in its entirety. Throughout this manual 
we have defined pieces of the one-family electro- weak model. The full listing of 
the class definition can be found in the appendix. Here we present the main 
code block where the physics analysis begins. We will then give two examples 
of using the model to study something of physical relevance. These examples 
are not intended to be useful physics studies, only illustrative examples of using 
a model. 

10.1 Main Code 

We have defined the model ElectroWeak in the file EW.h, found in the appendix. 
We now give the code which initializes the model and allows us to begin a physics 
analysis. 

#include "EW.h" 

#include <ef f ective/ef f ective .h> 

int main(int argc, char **argv) { 
try { 

// Begin by initializing the model 
ElectroWeak ew; 

Model: :readCommandLine(argc,argv,&ew) ; 
ew. couplingsC'ew.gar") ; 
ew. initializeO ; 

// Now lets load the values of the parameters 

ifstream parin; 

parin.openC'EW.dat") ; 

ew . loadParameters (parin) ; 

parin. closeO ; 

// Lets create a LaTeX stream, ew.tex 
of stream fout; 

Utils : : startLatexCew.tex" , f out) ; 

// ... insert physics analysis code here . . . 

// now lets clean up 
Utils : : closeLatex(f out) ; 
} catch(exception &p) { 

cerr << p.whatO << endl; 
return 1 ; 

} 

return 0; 



31 



} 



We will now discuss the new items in this code. We see that the hie effective . h 
must be included in order to use Effective. We also see that two new rou- 
tines Utils: : startLatexO and Utils: : closeLatexO have been used. The 
startLatexO routine takes a filename and a stream. It opens the hie into the 
stream and sets the behaviour so that all expressions will be printed in LaTeX 
format. One must then remember to set and unset the math mode of LaTeX 
appropriately, depending on what is being saved to the hie. This routine also 
prints a preamble so that the LaTeX hie can be used without editing to produce 
a document. The closeLatexO then prints the \end{ document} string and 
closes the stream. 

The code also contains the try { . . . } catch { . . . } statements in 
the code. Effective uses the C++ exception handling mechanism to deal with 
unusual behaviour and internal errors. The try/catch clause catches any errors 
that have not been dealt with. The catch block then prints the error message, 
hopefully allowing the user to understand what failed. If these try/catch clauses 
are not included, the errors may just cause a crash without any information why. 

10.2 Case Study 1: Higgs Potential vs. v 

We now turn our attention to the hrst of two examples of a physics analysis. 
This hrst one will produce a tab-delimited hlc which can be used with a plotting 
program to give the tree-level and one-loop potential as a function of the VEV. 
This is given by 

Parameter vev = ew.getParamO'HiggsVev") ; 
of stream datafile; 
datafile.openCpotData.dat") ; 
for (double v = -246.0; v<=246.0; v+=0.5) { 
vev = v; 

ex tree = ew. potential (Approximation : :TreeLevel) ; 

ex one = ew. potential (Approximation : :0neLoop) ; 

datafile « v « "\t" << tree.evalfO « "\t" « one.evalfO 

<< endl; 
ew.resetMassesO ; 

} 

datafile . close () ; 

Using the values of the parameters given in section 19.21 this code was used to 
produce figure 

10.3 Case Study 2: cosOw as a function of the SU(2) cou- 
pling 

We now turn to another observable. In this case we will look into the Weinberg 
angle, 9w- The definition of the angle is Mw = Mz cos Qw- Thus we can study 
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Figure 2: The dependence on the tree- level (solid) and one- loop (dashed) effec- 
tive potential as a function of v. 



the ratio Mw/Mz at tree-level or one-loop. The following code produces a 
tab-delimited file which can be plotted. The result is shown in figure In this 
example we fix the U(l) coupling to 0.355 and the Higgs VEV, v, to 246.0 GeV. 
All values arc for the renormalization scale [i = 91.2 GeV. 

ofstream cosW; 
cosW.openC'cosW.dat") ; 
double lowg, highg; 

double fourtyPct = ew.getParameter("SU2") .to_double ()*0.4; 

lowg = ew.getParameter("SU2") .to_double()-f ourtyPct; 

highg = ew.getParameter ("SU2") .to_double()+f ourtyPct; 

idx i = ew. getGaugeGroup("SU2")->gauge Index () ; 

ex W = ew.getGaugeField("W")->expression() .subs(i==2) ; 

ex Z = ew.getGaugeField("W")->expression() .subs(i==3) ; 

ex MWt = Mass (&ew,W,MassCorrections : :treeLevel) ; 

ex MWo = Mass (&ew,W,MassCorrections : : oneLoop) ; 

ex MZt = Mass(&ew,Z,MassCorrections: :treeLevel) ; 

ex MZo = Mass(feew,Z,MassCorrections: :oneLoop) ; 

for (double g = lowg; g<highg; g+=f ourtyPct/20 . ) { 

ew.getParameter("SU2") = g; 

ew . resetMasses () ; 

cosW « "\t" « MWt.evalf O/MZt.evalf « "\t" 
« MWo.evalf ()/MZo.evalf () « endl; 

} 
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11 Customizability 

Throughout this text we have referred to Effective's modular design and the 
ability for a user to create extensions to study many different classes of models. 
One extension that may be of use is to implement a different group structure. 
Implementation of such a class is given in Appendix B.3 of |14) and repeated in 
tutorials on the website. 

What we will discuss here is how to implement new objects to provide be- 
haviours that differ from the default implementations. This includes a new sub- 
class of the Spin class as well as new Field classes. One may wish to implement 
special operators which act on terms in the Lagrangian. This is also discussed 
below. Lastly, a user may wish to use their own renormalization scheme and 
thus provide a different set of one-loop corrections. They may also have a closed 
form of a mass correction to a given order. These types of customizations are 
discussed here. 

11.1 New Operators 

Effective has a built in treatment of Lorentz derivatives. This includes knowl- 
edge of how to treat the Lorentz indices in compound terms which contain sev- 
eral Lorentz derivatives and vector fields. A user can define their own operator, 
but if this operates on fields, then the appropriate treatment of the operator 
must be included in the Spin class as discussed below. 
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In this part we will simply discuss what is needed to define the actual op- 
erator. We will take, as a concrete example, the idea of a light-cone operator, 
(ra This operator takes any Lorentz vector and projects it to either the plus 
or minus part of the light cone. In this example, the light-cone operator needs 
two arguments, the object which is being projected (e.g. momentum or vector 
field) and the sign. 

Code details of the definition of this object can be found in the GiNaC 
tutorials ^Uj. Here we present only the code and how the different parts cause 
the behaviour we desire. We begin with the class definition. 

const unsigned TINFO_LightCone = 0xll00008U; 

class LightCone : public basic { 
GINAC_DECLARE_REGISTERED_CLASS (LightCone .basic) ; 

private : 

bool itsSign; 
ex itsField; 

public : 

LightCone (const ex fearg, bool plus); 
LightCone (const LightCone &lc) ; 

// virtual functions 

void do_print (const print_context &c, unsigned level = 0) 
const ; 

void do_print_latex (const print_context &c, 

unsigned level = 0) const; 
ex eval(int level=0) const; 
ex evalf(int level=0) const; 
ex op(size_t i) const; 

ex & let_op(size_t i) { return itsField; } 
size_t nopsO const; 

bool signO const { return itsSign; } 

>; 

We can see that there are only a few functions that need to be implemented. 
Here we give the implementation of the constructor and the comparison opera- 
tor. The other routines are trivial. 

GINAC_IMPLEMENT_REGISTERED_CLASS_OPT (LightCone, indexed, 
print_f unc<print_context> (feLightCone : :do_print) . 
print_f unc<print_latex> (&LightCone : : do_print_latex) ) ; 

LightCone: : LightCone (const ex fearg, bool p) 
: basic (TINFO_LightCone) , itsSign(p) { 
// Simply replace the lorentz index by a + or - 
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symbol 1st idxs ; 

LorentzStructure : :getlndices(arg,idxs) ; 

// Indicate an error for non Lorentz vector objects 

if (idxs. size () != 1) { 

cerr << "Called a light cone operator on a " 
<< "Lorentz tensor with rank != l.\n"; 

} 

itsField = arg . subs (idxs [0] ==LorentzStructure : :lorentzlndex(0)) ; 

} 

int LightCone :: compare_same_type (const basic feother) const { 
int signdiff; 

const LightCone &o = static_cast<const LightCone &> (other); 

if(o.sign() == signO signdiff = 0; 

else signdiff = o.signO ? 1 : -1; 

int valdiff = itsField. compare (o . itsField) ; 

if(valdiff) return valdiff; 

else return signdiff; 

} 

Here we see that in order to get a functional operator we have simply had to 
properly define the comparison of two objects (in combination with the routines 
in the header file, which are trivial). These few simple routines provide an 
operator which acts on an expression from GiNaC and is treated as its own 
algebraic object in the engine. 

Of course, this particular implementation may not be wildly useful. Instead 
one may which to write, in the evalO routine, code which applies to distribu- 
tive property to the expression passed to it. So for example (A^ + B^) 
properly returns A + + B + . Again these issues are explained in detail in the 
GiNaC manual and tutorials. 

11.2 New Spin Classes 

As discussed in section [21 the Spin class determines several properties which 
determine what terms enter the Lagrangian. It also provides routines which are 
used to derive the couplings of fields. In order to change these behaviours, a 
user must implement a new subclass of Spin. Here we will discuss the Spin 
class in detail and explain what each routine is used for. This will be a valuable 
reference for a user who wishes to implement new types of fields. 

We begin with table ^ Here we see the full list of routines in the Spin 
class and whether each routine is virtual or not. The virtual routines can be 
rcimplcmented by a subclass of Spin. 

We discuss here what each of the routines of the Spin class means and how 
a new implementation can be made. We will begin with the virtual routines 
which have a default behaviour. This means that these routines do not need to 
be reimplemcntcd by the user, unless they wish to change their behaviour. 
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Routine 



Arguments 



Return 



virtual interaction Field* 
virtual isLorentzIndex 
virtual imagPart 

virtual massCorrection ex, ex, ex, Model*, 

bool, bool 

virtual lorentzDerivativeCouplings ex, Couplings*, ex, 

ex , int , int 

virtual operator== const Spin & 

virtual clone 

virtual alternateOperatorCouplings ex, Couplings*, ex, 

ex , int 

virtual massMatrixCoef f 
virtual isMassSqrt 

spin 

coef f 



Couplings*, ex, ex, 
ex, ex&, int, bool 



getName 



Tabic 1: Complete list of routines for the Spin class. Details of each 
can be found in the text. 



ex 

bool 
bool 
ex 

epair 

bool 

Spin* 

epairv 

ex 

bool 

double 

ex 

string 

routine 



• isLorentzIndex () : This routine indicates whether fields of this spin have 
a Lorentz index or not. The default value is false. 

• imagPart ( ) : This specifies whether a field should have a real and imag- 
inary component (true) or just a real component (false). The default 
value is true. 

• alternateOperatorCouplings () : This routine is used to find the cou- 
plings of a field of this spin in the Lagrangian when non-default operators 
have been implemented. This means that if the user has implemented 
their own operator which acts on terms in the Lagrangian. they must also 
implement this routine for all field types which are operated on by the 
new operator. This routine takes arguments we will label here as f , c , 
x, idx, level. The derivation of couplings is a recursive procedure in 
Effective. The procedure which derives the couplings will call this rou- 
tine at every level of recursion. It is the responsibility of this routine to 
return a list of expression pairs (epairv) which each contain a new index 
and value for the coupling. This coupling is the derivative of x with re- 
spect to the new operator Oi acting on f , i.e. oo\j) ■ Each clement of 
the list is for each additional new operator that has been defined. The 
new index is given by the old index, idx, times the field acted upon it by 
Oi. The level argument is an integer which indicates how many levels 
of recursion are still to be done. In some cases this can be quickly used 
to decide whether to perform the derivative on x or not, thus speeding up 
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the routine considerably. By default this routine returns an empty list. 

• massMatrixCoef f () : This routine returns an expression which is a co- 
efficient used for the mass matrix calculation. The mass matrices are 
computed by cqn. (|26|l . where the coefficient is simply the sign. This fac- 
tor is usually just a sign, but this implementation allows it to be whatever 
the user requires. The default behaviour is just to return 1. 

• isMassSqrt () : This routine indicates whether the mass matrix requires a 
square root (true) to return the mass or not. For example the vector and 
scalar matrices give the mass squared whereas the fermion mass matrix 
gives only the mass. The default value is true. 

We now turn to the non-virtual routines. These cannot be overwritten. Instead, 
they are just simple wrappers or data access routines. The constructor for a 
Spin object takes a string and a double value. This string is the name of the 
spin type and the double represents the spin factor, i.e. (2s — 1)(— l) 2s . The 
non- virtual routines are: 

• spinO : This routine returns the value of the spin factor given to the 
constructor. 

• getName ( ) : This routine returns the name of this spin type given to the 
constructor. 

• coeff () : This routine is a wrapper which takes the Couplings pointer 
as well as the field and expression to differentiate and performs the dif- 
ferentiation. This routine also takes an extra argument, the ex&, which 
is modified to represent the new index after differentiation. The Lorentz 
structure of the index may not be unique in a brute force type of imple- 
mentation. In order for the index to be unique for a given set of fields 
the differentiation is performed and the appropriate transformations of 
the Lorentz indices is applied so that the index is always unique for a 
given set of fields, and the coupling times that unique index is the correct 
expression from the Lagrangian. The final argument is a boolean which 
indicates whether to let the Couplings class handle the Lorentz index 
substitutions (false) or not. 

We finally now turn our attention to the virtual functions which have no default 
implementation in the Spin class. These routines must be reimplemented by a 
Spin subclass in order to be used. 

• interactionO : This returns the kinetic terms of the field of this spin 
type. This is the routine that must be changed implement different terms 
in the Lagrangian. 

• lorentzDerivativeCouplings () : This is similar to the previously dis- 
cussed alternateOperatorCouplings () routine. This routine is only for 
Lorentz derivatives and rather than return a list of expression pairs it 
returns only one (epair). 
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• operator==() : This is a simple comparison routine. If the two spin 
objects are identical, then true is returned. 

• clone () : This routine creates a new object which is identical to the one 
it is called on. This routine dynamically allocates a new pointer, it is the 
responsibility of the calling method to handle the memory deallocation. 

Now we have discussed in detail the methods of the Spin object we must explain 
how a new spin class can be included into the framework of Effective. The 
default behaviour of Effective is to include the ScalarSpin, FermionSpin 
and VectorSpin spin types. A user can add a new Spin subclass by calling 
Model: :addSpin() before the initialize () routine is called. A logical place 
is in the constructor or the createMatterFieldsO or createGaugeFields () 
routines. The addSpin routine will add the new spin to the list of spins. Each 
spin type in this list has a corresponding mass matrix. This means that only 
fields with the same Spin classes will mix. 

It is also possible to create a new Spin class which replaces on of the default 
ones. In order to tell Effective to use the new class instead of the old one, 
the user must call Model: : changeSpinO . This routine takes the new spin 
object and an index to one of the old ones. This index is either Model : : Scalar, 
Model: :Fermion or Model: : Vector. Again, this routine needs to be called 
before the initialize () routine. 

11.3 New Field Behaviours 

Another major modification that a user may want to implement it to define a 
new type of field. For example, currently Effective does not provide a way 
for a field to be in the adjoint representation of a group and be charged under 
other groups. This is done, for example, in models with Higgs triplets |15j . 

Here we will give the outline as to the method to create such a field. The 
MatterField will be our starting reference. In fact, this almost completely 
describes our new field, except we need a list of flags to indicate which groups 
are in the adjoint representation and which are in the fundamental. One would 
then, when creating the list of indices, add the adjoint index to the list (which 
is retrieved by GaugeGroup: :gaugelndex) rather than the fundamental index 
(retrieved with GaugeGroup: : matter Index). The only other changes required 
would be to the covariantDerivative () and susyO, where instead of using 
the generators, the structure functions would need to be applied for the adjoint 
representation. Lastly, theField: :Cr() andField: :C2() functions would have 
to be defined to return the correct values for the adjoint representation. 

As long as this new class is a subclass of Field we can immediately use it 
with Effective to study this new class of model. In fact, such an extension 
will be included in a future version of Effective along with improvements to 
the Field class to allow for a more natural extension to N ^ 1 SUSY and higher 
rank tensor fields. Though all of these are possible now, it would be difficult to 
make everything work in a natural way. Changing some underlying structures 
will simplify such extensions. 
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11.4 New One-Loop and Beyond Mass Corrections 

The last major customization a user can implement is the mass corrections. 
The Mass class constructor takes three arguments. The model, the field and a 
MassCorrection class. This class has one virtual routine, operator (), that 
must be implemented. In Effective there are four types of MassCorrection 
classes implemented. These are discussed in section Here we discuss what 
operatorO calculates so that users can implement their own version. 

The operatorO routine has the arguments: BlockMatrix &, Spin*, and 
Model*. This routine is called by the Mass and MixingAngle classes when 
evaluated. The BlockMatrix class contains the undiagonalized, diagonalizcd 
and the rotation matrix for tree-level and matrices for the correction (at any 
order) and the diagonalizcd result and the rotation matrix (also at any order). It 
is the operatorO routines job to take the undiagonalized tree-level matrix and 
generate the mixing matrix and the diagonal values of the matrix, at any order. 
It is then up to the user to implement their corrections and the diagonalization 
of the mass matrix how they wish. 

This procedure will become clear after we look at the OneLoopMassApprox 
implementation. This class gives the approximate one-loop mass, but only the 
tree-level mixing matrix. This is done by computing only the diagonal correc- 
tions to the diagonalizcd mass matrix. 

void OneLoopMass :: operator () (BlockMatrix &bm, Spin *s, 

Model *m) { 
if (MassMatrix: :rediag(bm)) { 
int temp; 

matrix r = bm.undiag; 

Utils: :diagonalize(r,bm.diag,bm. rotate, temp) ; 

> 

if (bm.lastFlag != flag) { 

Utils : :matrixCopy (bm. correction, correct ion (bm,m, s) ) ; 
Utils : :matrixCopy (bm. crotate ,bm. rotate) ; 
Utils : :matrixCopy(bm. cdiag,bm. correction) ; 
ftime(febm.lastDiag) ; 
bm.lastFlag = flag; 

} 

} 

This code simply checks that the parameters haven't changed, and if they have 
rcdiagonalizes the tree level matrix. If the last evaluation wasn't the same 
approximation as this one, this method then computes the corrections to ma- 
trix. From this one can imagine how they may implement a different type of 
correction. For example, the correctionO routine which is called to fill the 
correction matrix with its values, may contain clauses to identify specific parti- 
cles and apply corrections derived from a paper for a particular particle. 
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12 Future Outlook 



This article has been designed to serve a few purposes. We have described many 
of the important tools that allow a user to probe the physics of their model as 
they see fit. This gives users a manual by which to begin to implement their 
model. 

We have also explained the assumptions and physics behind the code. This 
way a user is able to know what to expect from the default behaviour of the 
library, and design extensions that suit their needs. We have discussed several 
extensions that are possible. These are the ones that we feel are likely to be 
most useful for users. 

We have not provided detailed code documentation nor a list of all possible 
extensions. This has been reserved for the website, which will contain tutorials 
with detailed code. 

Throughout this text we have discussed future improvements we plan to 
make on the code. The status of such improvements can be found on the 
webpage. The most pressing upgrades we would like to implement are the 
following: 

• We plan to generalize the Field implementation so a wider range of models 
can be easily implemented. 

• For many models some symmetries, for example SU(3)c, are unbroken. 
It may be desirable to not explicitly sum over the indices of these groups, 
except when computing numerical results. 

• Properly provide a supermultiplet object which can be used to define the 
supcrpotcntial. 

• Automate the one-loop RGE for at least one renormalization scheme. 
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A ElectroWeak definition 

We present here the full definition of the ElectroWeak class. Here we define it 
in one file, EW.h, though the class definition and the routine implementations 
could be separated into two files. 

#ifndef EW_H 
#define EW_H 

#include <ginac/ginac .h> 
#include <ef f ective/ef f ective .h> 
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#include <f stream. h> 



const unsigned int SU2w = 2; 
const unsigned int Ulb = 1 ; 

using namespace std; 
using namespace GiNaC; 
using namespace Effective; 

const int famsize = 1; 

class ElectroWeak : public Model { 
public : 

ElectroWeak O : Model () {} 

virtual void createGaugeGroupsO ; 

virtual void vreateGaugeFieldsO ; 

virtual void createMatterFields () ; 

virtual void addOtherTerms () ; 

>; 

void ElectroWeak :: createGaugeGroups () -[ 

addGaugeGroup (new UIGroupC'Ul" , "{g'}", this, Ulb)); 
addGaugeGroup (new SU2Group("SU2" , "{g_W}", this, SU2w) ) ; 

} 

void ElectroWeak :: createGaugeFields () { 
VectorSpin v; 

addFieldC'B" ,new GaugeField( "B" , "B" ,v,getGaugeGroup("Ul") ) ; 
addFieldC'W" ,new GaugeField( "W" , "W" ,v,getGaugeGroup("SU2") ) ; 

} 

void ElectroWeak :: createMatterFields () { 
numeric half (1,2); 
ScalarSpin s; 
FermionSpin f ; 

GaugeGroup *ul = getGaugeGroupC'Ul") ; 
GaugeGroup *su2 = getGaugeGroup("SU2") ; 

addFieldC'l" , new MatterFieldC'l" , "Well", f , famsize, 

ul,-half ,su2,l)) ; 
addFieldC'eR" , new MatterFieldC'eR" , "e_R" ,f , famsize ,ul , -1) ) ; 
addFieldC'H" , new MatterFieldC'H" , "H" , s , 1 ,ul ,half , su2 , 1) ) ; 

// Now add Higgs Vev 

Parameter upsilon = addParameter ("HiggsVev" , "upsilon" , 246 . , 

Parameter: :vev) ; 
addVev( "HiggsVev" ,getField("H") ,lst(getIndex("H" , "SU2")==2) , 
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(upsilon+Model : : star) ) ; 
addVevParameter (upsilon) ; 

> 

void ElectroWeak: : addOtherTerms () { 
// Create mu~2 H H 

Parameter mu = addParameter ("mu" , "\\mu", 1.0); 
vector<idx*> indices = getField("H")->getIndices() ; 
ex H = getField("H")->expression() ; 
ex a = pow(mu, 2) *H. conjugate ()*H; 
add(Utils : : sumlndices (a, indices) . expandO ; 

// Create lambda * (HH)"2 

Parameter lambda = addParameter ("lambda" , "lambda", 1.0); 
ex la = Utils :: sumlndices (H . conjugate () *H, indices) . expandO ; 
add(-lambda*pow(la, 2) ) ; 

// Now add lepton Yukawa 
ex Ye ; 

if(famsize != 1) Ye = addFamilyMatrixC'Ye" , "{Y~e}" ,f amsize) ; 
else Ye = addParameter ("Ye" , "{Y-e}", 1.0); 
idx j = Utils :: familylndex(l , f amsize) ; 
ex eR = getField("eR")->expession() ; 
ex 1 ; 

if(famsize != 1) 1 = getField("l")->expression() . conjugateO 

.subs(Utils: :familylndex(0,famsize)==j) ; 
else 1 = getField("l")->expression() .conjugateO ; 
ex b = -Ye . subs (j==Utils :: family lndex(0 ,f amsize) ) *l*H*eR; 
indices = getField("l")->getIndices() ; 
if (f amsize != 1) indices .push_back(&j) ; 
ex res = Utils :: sumlndices (b, indices) . expandO ; 
add(2*Utils: : real (res)) ; 



B Summary of Classes and Routines 

This appendix provides a summary of some of the more important routines 
discussed in this article. 

B.l Classes and Routines Used for the Field Content 

In this section we present a summary of the classes and routines that are needed 
to define the field content of a model. 

Table|3givcs a list of the classes encountered when defining the field content. 
This is intended to give a brief synopsis of the relevant classes one should use 
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when defining ones field content. 



Class 



Description 



GaugeGroup 

UIGroup 

SU2Group 

SU3Group 

Spin 

ScalarSpin 
FermionSpin 



VectorSpin 
Field 

GaugeField 

MatterField 

Parameter 



Abstract class defining the behaviour of a group 

The definition of the U(l) group 

The definition of the SU (2) group 

The definition of the SU (3) group 

Abstract class defining behaviour of spin objects 

Definition of the scalar spin behaviour 

Definition of the fcrmion spin behaviour. This is specific 

to the Weyl fermions. A new class is needed for Dirac 

fcrmions 

Definition of the vector spin behaviour 

Abstract class of a set of fields with the same properties 

Class specific to fields which mediate the interactions 

Class which describes the remaining fields 

Analytic object with a numeric value which can change 



Table 2: Table of the classes used to define the field content. 

Table |21 gives the list of routines which are used to define the field content. 
The first column gives the routine; all routines in the table are found in the 
Model class. Information on the arguments to the routines can be found in the 
text of the previous sections, or online at the URL given in the first section. 



Routine 



Description 



addGaugeGroup 
addField 
addParameter 
addVev 

addVevParameter 

getGaugeGroup 

getField 

getGaugeField 

getMatterField 

getParam 

getParameter 



Adds a new group to the model 

Adds a field to the model 

Adds a new parameter to the model 

Adds a vacuum expectation value to the model 

Tells model Parameter is a VEV 

returns the pointer to the gauge group 

returns a pointer to a Field 

returns a pointer to a GaugeField 

returns a pointer to a MatterField 

returns a Parameter object 

returns a numeric object 



Table 3: Routines used to define field content. 



The Model class is an abstract class. The user must define their own concrete 
version of this class which contains their field content. Table 01 describes the 
routines needed to define the field content of of the concrete class. 
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Routine 



Description 



createGaugeGroups 
createGaugeFields 
createMatterFields 

addOtherTerms 



Routine where the GaugeGroup objects are defined 
Routine where the GaugeField objects are defined 
Routine where the MatterField objects are defined 
and the VEV are given 

Routine to define any other terms in the Lagrangian 



Table 4: Routines which are virtual in the Model class and must be implemented 
by the user when defining their model. 



B.2 Classes and Routines Used for the Interaction Terms 



Table gives the list of routines in the Model class that were used for creating 
the interaction terms. 



Class Routine 



Description 



Model addFamilyMatrix 



Model getFamilyMatrix 



Model 
Field 
Field 



Utils 
Utils 



add 

expression 
getlndices 



f amilylndex 
sumlndices 



This creates a matrix with a unique Parameter 
for each individual element. One can retrieve 
the whole matrix with getFamilyMatrix () 
or each element with getParameter () or 
getParamO . 

This returns the matrix (with unreferenced 
indices) given by the input string. 
Add the expression to the Lagrangian. 
Returns the (complex) expression for a field. 
Returns all of the indices (except Lorentz) 
for a Field. There is an optional argument 
which when false removes the family index 
from the list. 

Returns a symbolic index for the family space 

from a predefined list of indices. 

Sums the expression over the indices given. 



Table 5: List of classes and routines used for the interaction terms. 



B.3 Classes and Routines used for the Effective Potential 

Here we summarize the classes and routines which were needed to deal with 
the effective potential. Table [5] gives the descriptions of the two routines in the 
Numerics class that were encountered. 

Table[7|shows the routines in the Model class which were used with the effec- 
tive potential. We have also introduced the enumerated type Approximation : : - 
Approximations and two possible values it can take, Approximation: :TreeLevel 
and OneLoop. 
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Routine Description 

extremizePotential This routine takes a list of Parameters and finds 
the values which minimize the effective potential. 
This routine also takes an approximation which to 
use when evaluating the potential. This numerical 
routine is based on the direction set (or Powell's) 
method in multidimcnsions. 

solveZeroTadpoles This method is similar to the previous one except 
it takes a list of Parameters and finds the values 
which give tadpoles which are equal to 0. This 
method can also take different approximations to 
use to evaluate the tadpole diagrams. This method 
uses the Ncwton-Raphson root finding method. 

Table 6: Routines in the Numerics class used for the effective potential and 
tadpoles. 

Routine Description 

tadpole Returns the values of the tadpoles for the current values 
of the parameters. This routine takes an argument which 
specifies what approximation to use when evaluating the 
tadpoles. If none is given the default result is the 
tree-level tadpoles. 

potential Returns the effective potential for the current values of the 
parameters. If the approximation given is tree-level (default) 
then the result is returned analytically. If the approximation 
is one-loop then it is returned numerically. 

Table 7: The two routines of the Model class which were discussed in section[3] 

B.4 Classes and Routines for Masses and Mixing Angles 

Table[H]shows the two constructors of the classes Mass and MixingAngle. These 
classes are GiNaC objects that can be used in expressions. The value of them 
is not evaluated until a call to evalf () is made. This means the user can create 
expressions as functions of the masses and mixing angles of their model and trust 
that the values will take the appropriate values each time evalf () is called. In 
order to make this process more efficient, the masses aren't re-evaluated every 
time evalf () is called. They are re-evaluated if one of two conditions holds. 
The first is that the approximation being used is different than the last one 
used. The second condition is if a flag has been set to force re-evaluation. This 
is provided by the function Model: : resetMasses () . 

Tabic provides a summary of the four mass corrections provided in Ef- 
fective. 
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Constructor 

Mass (Model* , ex ,MassCorrection) 



MixingAngle (Model* , ex 

ex,MassCorrection) 



Description 

This constructor takes a Model pointer 
and a field and provides a GiNaC 
object which evaluates the mass of the 
field under the given approximation. 
This constructor is similar to the Mass 
constructor except it takes two fields. 
This provides the value for element 
given by the two fields of the rotation 
matrix used to diagonalize the mass 
matrix. 



Table 8: Description of the Mass and MixingAngle constructors. 
Class Description 

TreeLevel Simply diagonalizes the tree level mass matrix 

OneLoopMassApprox This uses the tree level diagonalized mass matrix 

and computes corrections to the diagonal elements 

only. 

OneLoopMass Solves, for p 2 , the determinant equal to 

in cqns. fJJJ and (ggjl. 
DneLoop This uses the same approach as OneLoopMass 

and also computes the one-loop mixing angles. 

Table 9: The four default mass corrections provided in Effective. 



B.5 Classes and Routines for the RGEs 

Section [3 introduced a new class RGE. This class was responsible for properly 
treating the RGEs and the evolution of parameters between scales. In this 
version of Effective, this class is simple and requires the user to input the 
expressions for the (3 functions. It is planned that in future versions, an auto- 
matic one-loop calculation for all parameters will be provided for at least one 
rcnormalization scheme. 

Table shows a list of the routines of RGE that have been described and 
used in the discussion of the RGEs. 



C Effective Potential Review 

We will begin by deriving the effective potential. We will then show how the 
one-loop effective potential can be derived in a model-independent way. This 
means that the one-loop correction only depends on the masses of the model, 
not explicitly on the couplings. This review is derived from . The interested 
reader can find a more thorough discussion there. 

We begin by considering a theory of one scalar field <f> with a Lagrangian 
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Routine 



Description 



evolve This evolves the parameters from the current scale to 

the scale provided. 

initial-Condition This routine allows the user to define the default value 
of a parameter at a particular scale. None of the 
initial conditions need be defined at the same scale. 

applylnitial This routine takes a scale, [i, and a 8 value as 

arguments. It then finds all parameters with initial 
conditions defined at the ^ ± 8 and applies them. 

print This prints the analytic form of the f3 functions to the 

stream provided. 

Table 10: The list of routines of the class RGE. 



density C{4>(x)}. The action is given by 

Sy>] = [ ^xCicj)}. (43) 



The vacuum-to- vacuum expectation value (0 ou t|0in)j is given by 

Z\j) = (OoutlOm),- s yx>0exp{i(S[0]+#)}, (44) 

where 

<f>3 = J d*X(j>{x)j{x). (45) 

We can define the connected generating functional, W[7'], in terms of the vacuum- 
to-vacuum expectation value 

Z\j] =exp{iWV\}. (46) 

We now define the effective action, r [</>], for S[<p] such that its classical field 
equation is the solution to the Schwingcr-Dyson equation for S[<f>], That is, we 
require T'[<p] = j. Solving this equation gives 

j4 SW\j] 



where 



Sj{x) 

4>{x) is then a weighted average of the fluctuations of the field <fr. In a transla- 
tionally invariant theory, this is a constant. Effective is designed to only deal 
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with translationally invariant theories, therefore, 4>{x) must be a constant, <fi 
which is the VEV of the field. The effective potential can then be defined as 



r[0 c ] = -J d 4 xV cS {^ c ). 

We now write this as an expansion around <fi c = 

oo 



(49) 



(50) 



n=0 



where the rw are the one-particle irreducible (1PI) Green functions. If we now 
minimize the potential over the constant field 4> c we find the vacuum state of 
the theory. 

At tree level, the effective potential, eqn. (|50J) . is identical to the classical 
effective potential. This can be stated simply as 



Vtr 



= -£( 



:■)■ 



(51) 



We now discuss the one-loop correction to this potential for a model with one 
self-interacting scalar field. The results will generalize to all fields. This simple 
model is given by 



(52) 



As just shown, the one-loop correction to the tree-level effective potential is 
given by the sum of all 1PI diagrams with a single loop and zero external 
momenta. The nth diagram has n propagators, n vertices and 2n external legs. 
The propagators contribute a factor of i n (p 2 — m? — ie)~ n . Each pair of external 
lines contributes a factor <jy^ n and each vertex a factor —i\/2. Including a global 
symmetry factor we have 



n=l 

~2 



d 4 p 1 
(2tt) 4 2n 

d A P . 
log 



(27T) 



1 - 



2 2 

— m — 



After a Wick rotation in the DR scheme JJ] this is 



64tt : 



: m 4 ((^ c ) ( In 



m 2 {<t>c) 



(53) 



(54) 



where 



m 2 ((/> c ) 



(55) 



is the tree-level mass and \i is the renormalization scale. 
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D Passarino Veltman Functions 



In this appendix we provide the definitions of the Passarino- Veltman func- 
tions ^3 that are provided in Effective. These can be accessed by calling, for 
example, Passarino_Veltman : :A0(). The derivatives can be found by calling 
the GiNaC diff () routine. 



A (m 2 ) 
B a {p\ m \,ml) 



16tt 2 f id d q 1 



^ d - 4 J (2ir) d q 2 - m 2 + ie' 
16tt 2 f id d q 1 



fi d ~ 4 J (2ir) d (q 2 -mj + ie) ((q + p) 2 - m\ + ie) 



n R (r? rr, 2 m 2\ - ^ f ^ 5 " 

Pp±Si[P ,m 1 ,m 2 ) 



/i d " 4 J (2ir) d {q 2 - m\ + ie) {{q + p) 2 - m 2 + ie) 
g^B m (p 2 ,ml,m 2 2 ) + p^p v B n {p 2 ,m\,mi%) 

16n 2 f id d q q^q v 



p d - A J {2-K) d (q 2 -m\ + ie) ((q + p) 2 - rof + ie) ' 
The first two, Aq and Bq, can be expressed to 0(e) for d — 4 — 2e as 

A (m 2 ;n 2 ) = m 2 f + +0(e), 



B (p 2 ,m 2 ,m 2 ^ 2 ) = i-ln^-/ B (s+)-/ B (x_)+0(e). 

£ jlT 



In Effective we subtract only the terms proportional to 

— = 7_e + ln47r. 

£ £ 

We also have 



s ± \l s 2 — Ap 2 (m 2 + ie „ , . , . , , / 1 
y. 2 J { - 1 , f B (x) = ln(l-z) -xln (l-- 



and s = p — to 2 . + to 2 . 

E Mass Corrections 

In this section we provide the formula for all of the model independent one-loop 
mass corrections. 

E.l Scalar-Scalar 

We now define the contributions to the two-point Green functions for scalar 
fields. There are 6 classes of diagrams which can contribute to the full two-point 
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Green function for scalar fields: two four-point diagrams and four three-point 
diagrams. 

The four-point diagrams have an internal field as a vector or a scalar. We 
designate these two contributions as II s4 and H VA . It is assumed that the scalar 
four point coupling is a simple scalar quantity, Cs4, where the vector four-point 
coupling is a tensor of the form Cy^g^ v . The contributions are then 



n s V,m 2 ;^) = ^A (m 2 ; M 2 ), 



I^V,m 2 ;/?) = -^A (m 2 ;y 2 ). (57) 

The spin of the internal fields for the three-point diagrams can be pairs of 
all three types of spins, as well as a vector-scalar pair. We designate these 
contributions as II s3 , II^ 3 , ±l y3 and n vs . We assume that the scalar and fermion 
three-point couplings are simple scalar quantities, C53 and Cf3 respectively. 
This leads to the contributions 

n s V,m 2 ,m 2 ;A1 2 ) = ^|^ ( p 2 , TO 2 , m 2 ;/i 2 ), (58) 

dc { Jlc {2) 



U F3 f^ 2 ™ 2 ™ 2 - ,, 2 \ — -F3 ~F3 \J2( U / 2 2 2. ,,2\ 

11 (p ,m 1 ,m 2 ,n ) - — — [p (Bi{p ,m 1 ,m 2 ,y ) 

+Bi 1 (p 2 , m\ , ml ; /j 2 ) + dB 00 (p 2 , m 2 , mf. ; y 2 ) 



+mim 2 B (p 2 ,ml, m\\ y 2 )] , (59) 

where the superscripts differentiate between the two vertices in the three-point 
diagram. 

The vector three-point coupling is assumed to have the Lorentz structure 
Cv3ff M " '■ Again, using the Feynman gauge, this gives 

II^V,m 2 ,m 2 ; M 2 ) = B (p 2 , m 2 , m 2 ; M 2 ). (60) 

Lastly we turn to the scalar-vector three point coupling. It is assumed that these 
couplings are derived from terms in the Lagrangian CysfjO^fiA^g^. This 
means we must consider the derivative to lie on both the external and internal 
fields. Since we have two couplings of this type we find three contributions: the 
derivative is on both of the external fields, the derivative is on both the internal 
fields, and the derivatives lie one on the external and one on the internal. These 
are denoted by II^ S , ny s and nyj , respectively, and are given by 

^(1)^(2) 

TfVSf „2 2 ™2.,,2\ _ °VS U VS „2 p / 2 2 2 . ,,2\ ( M \ 

107T 
^(1)^(2) 

ttVS/ 2 2 2 2\ °VS U VS [ 2n / 2 2 2 2\ 

+dB m ( P 2 1 m 2 ,m 2 ;y 2 )} (62) 

TjVSfJZ 2 ™2.,,2\ _ WsWS „2 H /„2 2 2 . ,,2\ / R o<i 

LL IE [p ,m v ,m s ,/j, ) - p Bi[p ,m v ,m s ,fj, ). {bd) 
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To get the total contribution for the vector-scalar three point coupling we must 
sum these terms, i.e. U vs = itf s +U^ S +2Uj£ , where the factor of 2 is from the 
two combinations of placing the derivative on the internal and external fields. It 
is also worth noting that the couplings between the three contributions in eqn. 
I|6 11631) do not have to be equal. 

In order to get the complete scalar-scalar two-point Green function we must 
sum over all possible internal fields for each contribution. This is 

iW) = J2 

i G vector 

+ E 

iGscalar 

where the indices k and / represent the external scalar fields and indices i and j 
represent the choice of internal loop fields. Of course, in this sum many choices 
of i and j do not contribute as these fields don't couple to k and I. 
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E.2 Fermion-Fermion 



The fermion-fcrmion self energy consists only of three point coupling diagrams 
with a a fcrmion-vector or a fermion-scalar internal loop pair. The scalar- 
fcrmion vertex is assumed to be a simple scalar coupling, C$, while the vector- 
fermion coupling is assumed to be of the form Cy7^- The contribution from 
these diagrams are 



S S (i>,TO/,m|;^ 2 ) 
£ y (A fn 2 f ,my;n 2 ) 



^L±S-{£ Bl (p 2 , m 2 ,rn 2 ^ 2 ) 
+m f B (p 2 ,m 2 f ,m 2 s ,LJ, 2 )} 

^M(rf-2), 



16tt 2 

dm f B (p 2 ,m 2 ,my;^j, 2 )} 



I 2 2 2 2\ 

{p ,m f ,m v ;ii ) 



(65) 



(66) 



Again to construct the full two-point Green function one must sum over all 
possible choices of internal fields. The two-point Green function for fields k and 
I is 
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zGfermion 
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j'G scalar 



yS 
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j'G vector 



yV 



(67) 



E.3 Vector- Vector 

The vector- vector two-point Green function is composed of seven classes of dia- 
grams, two four-point coupling diagrams and five three-point coupling diagrams. 
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The four-point couplings diagrams contain either an internal scalar or vector 
field. The contributions from these diagrams are denote by 1$* and HY£, 
respectively. The scalar four-point coupling between scalar <p and vector fields 
A^A^ is assumed to have the form Cs4<? A " / , where Csa implicitly contains the 
a and b indices. The contribution is 

II^(/,mV) = ^<^A,(m 2 ;/?)- (68) 

The vector four-point coupling between vectors A% , A% , A x and A a d is given 
by C ( ylg^g Xa + d$\g* x g va + C^g^ ' g vX with the group indices a,b,c and d 

( 1 2 3) 

contained in the coefficients C v ^ ' . The contribution from the diagram is 

j r (l) , r (2) , ^(3) 
-nV4/ 2 2 2\ ^1/4 T i^y 4 1" a/1 2\ 1 a<\\ 

n My (p ,m \ n) = v —g^A {m ;pL ). (69) 

This result is found for d dimensions and in the Fcynman gauge. 

We now turn to the contributions from the three-point coupling diagrams. 
We begin with the diagram which contains a pair of scalars for the internal fields. 
The couplings for this diagram are assumed to come from a term Css^Pjd^ifiA 11 . 
As was seen for the scalar-scalar two-point Green function we must consider the 
placement of the derivative for both of the vertices. This means we have four 

S3(i j) 

possible contributions which we denote by 11^,, , for i, j = 1, 2. We have the 
first contribution when the derivative is associated with the first loop field (the 
one associated with mi) in both vertices. This is given by 

^(1,1)^(2,1) 

^3(1,1) /„2 2 2. ,,2\ _ °S3 °S3 r„ R (Ji ™2 2. „2\ 

vv nu IP > TO i) m 2-M ) Yq^z [9^^>oo(P ,rn 1 ,m 2l fi ) 

+ 2VP" S ii(^ m i> m i;M 2 )] ( 70 ) 

where C5.3 represent the coefficient of the term for the ith vertex where the 
derivative is placed on the jth field in the loop. Similarly we find for the 
remaining contributions 

^(1,2)^(2,2) 

ttS3(2,2) 1 2 2 2 2\ ^ S3 ^S3 I id i 2 2 2 2\ 

V ,"Ji J m 2 ;/ i ) = 16tt 2 \9^ b oo(P ,m 1 ,m 2 -fi ) 

+p^p 1/ B 11 (p 2 ,mj,ml;^ 2 )) , (71) 

^(1,1)^,(2,2) 

ttS3(1.2)/ 2 2 2. ,,2\ _ °S3 °53 („ R ( J2 2 „2. ,,2\ 

LL iiu (P > m i:W 2 ,/i J ~ \9^^oo(P ,m 1 ,m 2 ,n ) 

+p^p v [(B 1 + B 11 ){p 2 ,mlrr4; fJ 2 )]), (72) 

^(1,2)^(2,1) 

ttS3(2.1)/„2 2 2. „2\ _ °S3 ^53 /„ R f„2 2 _2. ,,2\ 
*- l Hv (P > m l:W 2 ,/i J - (Sm^OOIP ifln^/i J 

[(B a + Bh) (p 2 , m 2 , m 2 ; ^ 2 )] ) . (73) 

In Effective it also assumed that there is a symmetry between the terms of 
ipjdfMipiA* 1 and ipid^jA^ such that = C^ 2 "* for fc = 1,2. This means all 
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four terms have the same coefficient and can be added. Doing so one find the 
result 

n^(p 2 ,m 2 ,m 2 ;/z 2 ) = ^-p-p^Boip^mlmj-,^)- (74) 

We now turn to the fermion three-point coupling and the vector-scalar three 
point coupling. In the fermion case the coupling is assumed to take the form 
C Fd,9^ v 1 ni 1 ^ j A,, where CV3 is a scalar coefficient. The vector-scalar coupling 
is assumed to be Cvsg^ v ViA^A^, with Cvs a scalar. The contributions from 
these diagrams is then 



dC {1) C {2) 

U^(p 2 ,mlm 2 2 ; fi 2 ) = g^/ 3 [2p^ Pu (B 11 - B 1 ) - ( mi m 2 B 

2 



+ (d-2)B 00 -p 2 (B u -B 1 ))], (75) 

H^VX,™!^ 2 ) = -^S^^^^ 2 ^ 2 ^ 2 ), (76) 

where the arguments to the functions in the fermion contribution have been 
suppressed for simplicity. 

We then have the vector-vector three-point coupling. It is assumed that 
these are derived from terms like d ll A v A x A (7 (Cig' lX g u ' J + C 2 g^ a g vX )- When the 
derivative is permutated to lie on each possible vector field, this gives rise to 6 
scalar coefficients per vertex and 9 diagrams. Symmetries reduce this to only 5 
independent contributions. Due to the large number of contributions, these will 
not be listed here, but the sum will be denoted by II Jf 3 . 

Lastly, because the previous results were computed in the Feynman gauge, 
we must also include the three-point diagram where ghost fields are the inter- 
mediate fields. Contributions of this sort give a contribution 

16tt 2 

where again, we have suppressed the arguments of the functions on the right- 
hand side of the equation. 

As only the transverse components of the vector field propagate, only the 
transverse component of the Green function needs to be used in renormalization. 
This means that only the coefficient of the g^ v terms are used in the one-loop 
mass corrections. We denote this component for the Green function between 
vector fields k and I as ILj ; . Thus 



n ^(p 5 ' i m Gi> m G2i V 2 ) = 1fi 2 id^Boo + P^pv [Bi - Bu]), (77) 
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i j G ghost 



54 



where again the indices k and I are implicit in the couplings of the terms on 
the right-hand side. In Effective the ghost fields have the mass of the boson 
field with the same group charge. The ghost-ghost-vector three point coupling 
is assumed to be of the form gf abc . 
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